| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-22 | |||
| 14:27:49 | mriedem | i think that would fix an issue i had in libvirt driver tests with the multiattach stuff | |
| 14:28:02 | aspiers | isn't that what I did? | |
| 14:28:22 | mriedem | you did, but in the same patch that adds the amd sev capability | |
| 14:28:30 | mriedem | anyway nvm | |
| 14:28:34 | aspiers | oh, in a separate patch | |
| 14:28:37 | aspiers | yeah, I did wonder about that | |
| 14:28:46 | aspiers | happy to split it out! if you think it's worth it | |
| 14:29:30 | mriedem | it's fine to leave it | |
| 14:29:33 | aspiers | I'll do it :) | |
| 14:29:47 | aspiers | ah, I remember my thinking now | |
| 14:29:59 | aspiers | this is only required for drivers with dynamic capabilities, right? | |
| 14:30:22 | aspiers | but I missed the fact that multiattach is already dynamic | |
| 14:30:48 | aspiers | smaller patches -> easier quicker reviews | |
| 14:30:53 | aspiers | so I'll do it | |
| 14:37:13 | openstackgerrit | Merged openstack/nova master: Follow up for I0c764e441993e32aafef0b18049a425c3c832a50 https://review.openstack.org/638517 | |
| 14:39:31 | aspiers | mriedem: done https://github.com/aspiers/nova/compare/sev-deps...aspiers:sev-trait | |
| 14:40:54 | mriedem | aspiers: so why are these in github and not gerrit? | |
| 14:41:22 | aspiers | mriedem: because they depend on two unmerged patches which are not dependent on each other | |
| 14:41:23 | mdbooth | lyaaaaarwood: I think this needs a refactor into a separate test class: https://review.openstack.org/#/c/637527/ | |
| 14:41:39 | aspiers | mriedem: so I can't submit them in a series, because that would introduce an artificial dependency | |
| 14:42:14 | aspiers | and AFAIK Depends-On is only for cross-repo dependencies | |
| 14:42:39 | mriedem | what are the other 2 patches? | |
| 14:43:02 | aspiers | https://review.openstack.org/#/c/538498/ and https://review.openstack.org/#/c/633855/ | |
| 14:43:06 | aspiers | they are mentioned in the commit message | |
| 14:43:08 | sean-k-mooney | aspiers: it works withing the same repo too but when its in teh same repo it makes more sense to rebase on top of the patch | |
| 14:43:17 | mriedem | aspiers: your sev stuff can be rebased on top of https://review.openstack.org/#/c/538498/ yes? | |
| 14:43:20 | aspiers | sean-k-mooney: agreed | |
| 14:43:27 | mdbooth | aspiers: The practical solution is to have the artificial dependency. | |
| 14:43:43 | mriedem | yeah i'd just stack these all up | |
| 14:43:46 | mriedem | with https://review.openstack.org/#/c/538498/ at the bottom | |
| 14:43:52 | aspiers | mriedem, mdbooth: OK I'm totally fine with that if you guys are, thanks | |
| 14:43:56 | mriedem | and then https://review.openstack.org/#/c/633855/ | |
| 14:44:01 | mriedem | and then the stuff that sets the capability | |
| 14:44:07 | aspiers | yup | |
| 14:44:25 | aspiers | will do now | |
| 14:45:18 | dansmith | mriedem: done | |
| 14:45:27 | mdbooth | aspiers: If you find that a patch which isn't on the bottom gets +2s you can always rebase it to the bottom. If it's a clean rebase you'll retain the +2s and it can merge. | |
| 14:45:40 | aspiers | mdbooth: nice tip, thanks | |
| 14:45:52 | mdbooth | aspiers: It's not great, but it's kinda ok and doesn't usually come up that much. | |
| 14:46:10 | aspiers | I suspect Gerrit 2.16 will handle this better, as I mentioned the other day | |
| 14:46:13 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Don't emit warning when ironic properties are zero https://review.openstack.org/608611 | |
| 14:46:29 | aspiers | Oh, that wasn't in this channel | |
| 14:46:48 | lyaaaaarwood | mdbooth: pretty sure you can migrate between two backends on the same host | |
| 14:47:02 | lyaaaaarwood | mdbooth: that's what I've been testing locally at least | |
| 14:47:09 | lyaaaaarwood | mdbooth: they don't need to be different c-vols | |
| 14:47:50 | aspiers | Ah, it was :-) mdbooth: in case you missed it: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-02-12.log.html#t2019-02-12T22:08:56 | |
| 14:50:41 | lyaaaaarwood | mdbooth: https://developer.openstack.org/api-ref/block-storage/v3/index.html?expanded=migrate-a-volume-detail#migrate-a-volume - when the docs talk about migrating to a host they mean hostname@backend where hostname can be the same host still. | |
| 14:52:24 | mdbooth | lyaaaaarwood: Isn't that retype? | |
| 14:53:07 | kashyap | mriedem: Looking ... my IRC proxy dropped me off of Freenode | |
| 14:53:54 | kashyap | mriedem: Did you file a bug yet? Or shall I? | |
| 14:54:53 | lyaaaaarwood | mdbooth: https://developer.openstack.org/api-ref/block-storage/v3/index.html?expanded=migrate-a-volume-detail,complete-migration-of-a-volume-detail,retype-a-volume-detail#retype-a-volume - that's a totally different API | |
| 14:55:08 | lyaaaaarwood | mdbooth: where you can do the same thing, just with types that have backends defined in them. | |
| 14:55:20 | lyaaaaarwood | mdbooth: and again they take the form of hostname@backend | |
| 14:55:29 | lyaaaaarwood | mdbooth: so you can migrate between backends on the same host | |
| 14:55:38 | lyaaaaarwood | ^ sorry retype | |
| 14:56:37 | openstackgerrit | Adam Spiers proposed openstack/nova master: Change LibvirtDriver.capabilities to an instance variable https://review.openstack.org/638677 | |
| 14:56:48 | mdbooth | lyaaaaarwood: So retype and migrate are literally identical operations, just with different semantics for specifying the source and dest? | |
| 14:56:58 | mriedem | kashyap: https://bugs.launchpad.net/nova/+bug/1817324 | |
| 14:56:59 | openstack | Launchpad bug 1817324 in OpenStack Compute (nova) "Intermittent "Failed to start libvirt guest: libvirt.libvirtError: monitor socket did not show up: No such file or directory" failures in the gate" [Undecided,Confirmed] | |
| 14:57:08 | lyaaaaarwood | mdbooth: yeah pretty much | |
| 14:57:15 | kashyap | Thanks | |
| 14:57:37 | mdbooth | lyaaaaarwood: I don't understand, tbh. | |
| 14:58:10 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add detection of SEV support from QEMU/AMD-SP/libvirt on AMD hosts https://review.openstack.org/633855 | |
| 14:59:42 | kashyap | mriedem: On your comment in the bug; for that failure, the interesting stuff won't be in the QEMU guest log; it would be in the libvirt <-> QEMU interactions log (which the Gate captures) | |
| 14:59:59 | lyaaaaarwood | mdbooth: with migrate you provide the host (hostname@backend) you want to migrate to. With retype you provide a type you'd like to migrate to that can optionally contain a host (hostname@backend) extra spec that moves the volume | |
| 15:00:02 | mriedem | kashyap: i looked in the libvirtd log and didn't really see anything interesting | |
| 15:00:20 | mriedem | kashyap: besides stuff like it created the monitor for that instance and events weren't getting handled, something like that | |
| 15:01:23 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add new "supports_amd_sev" capability to libvirt driver https://review.openstack.org/638680 | |
| 15:01:36 | kashyap | Nod; /me still downloading the log | |
| 15:09:12 | frickler | mriedem: anything I can do to help with https://bugs.launchpad.net/nova/+bug/1815082 ? | |
| 15:09:13 | openstack | Launchpad bug 1815082 in OpenStack Compute (nova) ""DBNonExistentTable: (sqlite3.OperationalError) no such table: services" when starting nova-metadata under uwsgi" [Medium,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 15:09:30 | frickler | I'm also wondering whether this may be a duplicate actually https://bugs.launchpad.net/devstack/+bug/1814016 | |
| 15:09:31 | openstack | Launchpad bug 1814016 in devstack "Subnode required CELLSV2_SETUP=superconductor to be explicitly set" [Undecided,New] | |
| 15:15:46 | mriedem | frickler: ah i forgot about that | |
| 15:17:35 | frickler | mriedem: o.k., I'm assuming I did my part of the job, then. ;) | |
| 15:18:19 | mriedem | well n-api-meta is hitting conductor http://logs.openstack.org/77/635577/2/check/tempest-full/152e5bc/controller/logs/screen-n-api-meta.txt.gz#_Feb_08_16_53_34_572980 | |
| 15:18:32 | mriedem | i think | |
| 15:18:41 | mriedem | but it seems that the conductor it's hitting isn't up yet | |
| 15:20:15 | mriedem | we start n-api-meta here | |
| 15:20:15 | mriedem | http://logs.openstack.org/77/635577/2/check/tempest-full/152e5bc/controller/logs/devstacklog.txt.gz#_2019-02-08_16_52_32_215 | |
| 15:20:19 | frickler | http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/nova#n1096 | |
| 15:20:37 | frickler | that's in start_nova_rest, way before _conductor, yes | |
| 15:21:04 | mriedem | yeah n-super-cond is started here: | |
| 15:21:04 | mriedem | http://logs.openstack.org/77/635577/2/check/tempest-full/152e5bc/controller/logs/devstacklog.txt.gz#_2019-02-08_16_52_36_721 | |
| 15:21:44 | frickler | probably n-api-meta should idle a bit and retry | |
| 15:22:07 | frickler | even if we fix the order in devstack, we can't assume deployers will fine tune this everywhere | |
| 15:22:37 | mriedem | start_nova_rest is kind of weird - it starts nova-network as well which has always needed conductor to start first | |
| 15:22:39 | kashyap | mriedem: Oops: I think it is due to two 'pty' consoles getting reated...see lines 87-97 (from the n-cpu log): http://paste.openstack.org/show/745736/ | |
| 15:23:30 | mriedem | kashyap: would that be due to your recent version bump change? | |
| 15:23:34 | mriedem | which messed with the console code? | |
| 15:23:46 | kashyap | Yes, very much likely :-( | |
| 15:23:55 | kashyap | I fixed the s390x case, and I didn't see this at all in normal runs | |
| 15:23:56 | kashyap | Sigh | |
| 15:24:03 | kashyap | This seems to be 'isa-serial'-related | |
| 15:24:15 | mriedem | something something risk of doing this at the end of a release... | |
| 15:28:32 | kashyap | Yeah, I know what you mean. I made at least 3 folks to review, including the last person who reworked that code | |
| 15:28:55 | kashyap | I'll work towards fixing it as quickly as I can. | |
| 15:31:49 | mriedem | frickler: i think we're hitting the wrong conductor maybe | |
| 15:32:10 | mriedem | frickler: conductor is effectively started at 16:52:40 | |
| 15:32:14 | mriedem | n-super-cond that is | |