Earlier  
Posted Nick Remark
#openstack-nova - 2019-02-22
13:55:34 mriedem exactly
13:55:48 giblet mriedem: thanks for the help!
13:55:48 mriedem Selection object change to stash the traits will be an rpc change
13:55:53 mriedem np
13:56:08 giblet mriedem: good point about the rpc change. I don't want to start that 2 weeks before FF
13:56:22 mriedem and i dont want to have to think about it right now either :)
13:58:40 giblet mriedem: mentioning RPC change. Does the extension of InstancePCIRequest ovo also needs an rpc bump, here? https://review.openstack.org/#/c/625310/23
13:59:17 mriedem the object version bump is the rpc change
13:59:55 giblet mriedem: then we still have this rpc change in the bandwidth series unfortunately
14:00:20 mriedem sure i think that's fine - it's at least code you've already tested / demo'ed yeah?
14:00:32 mriedem i'd like to avoid *new* complexity with 2 weeks left
14:01:28 giblet mriedem: I've tested that code in the functional env. Not demoed yet as that code was not ready for the last demo in Berlin
14:02:32 giblet I agree to avoid new complexity added. heal allocation is still not finished and that has its own complexity
14:03:09 giblet I need to run some downstream errands, brb
14:10:52 mriedem dansmith: you want to make sure this is ok https://review.openstack.org/#/c/636210/ - i think it's just removing dead code at this point
14:15:11 aspiers mriedem, efried: the capabilities patch makes adding an SEV capability extremely easy! in case you're curious: https://github.com/aspiers/nova/commit/sev-trait
14:15:28 aspiers I can't submit to Gerrit yet because it depends on two patches which are not dependent on each other
14:27:24 mriedem cool, that's kind of the idea
14:27:36 mriedem you could break that down by moving the capabilities to the driver instance level rather than the class
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

Earlier   Later