| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-22 | |||
| 13:50:14 | mriedem | for host mappings and az queries | |
| 13:50:36 | giblet | mriedem: ahh I see. That is a pattern I can follow | |
| 13:51:57 | giblet | mriedem: do we handle re-schedule during multi-create in a special way or is it the same re-schedule code path? We have to call _fill_provider_mapping for the re-schedule too | |
| 13:52:39 | mriedem | same as single instance | |
| 13:52:48 | mriedem | the reschedule just gets 1 instance | |
| 13:52:57 | mriedem | a list of 1 i should say | |
| 13:53:23 | mriedem | that is rpc cast from compute here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2024 | |
| 13:53:52 | giblet | mriedem: then the cache would not work for re-schedule but the Selection object based soluton would work as re-schedule gets the Selection object too | |
| 13:54:15 | mriedem | we don't need the cache for reschedule since it's 1 instance | |
| 13:54:21 | mriedem | the cache is more for multi-create | |
| 13:54:48 | mriedem | but yeah again, short and long term optimizations | |
| 13:54:58 | giblet | if half of a multi-create hit the same faulty compute then we got a bunch of re-schedule at the same time | |
| 13:55:28 | giblet | but anyhow I will do a local cache for Stein as time is sort | |
| 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 | |