Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-10
16:28:58 sean-k-mooney the vif "objects" we store in the networkin info cache are dicts so its not versioned
16:29:10 sean-k-mooney but i would have to check the code to determin that
16:29:41 efried stephenfin: I don't think I can just use extra-specs-numbered-resource-groupings_ - because the renos and the docs are in separate repositories?
16:29:42 mriedem efried: https://docs.openstack.org/nova/latest/user/flavors.html#extra-specs-numbered-resource-groupings
16:29:59 mriedem unless nova-doc works in reno builds
16:30:10 stephenfin efried: https://docs.openstack.org/nova/latest/user/flavors.html#extra-specs-numbered-resource-groupings
16:30:13 stephenfin yeah
16:30:30 stephenfin it doesn't because release note builds aren't versioned
16:30:32 efried stephenfin: mriedem: Right, so I have to use the whole URL, okay. Thanks.
16:30:33 artom sean-k-mooney, oh, those VIFs. Well, we have what we need already, no? ovs_hybrid_plug and type
16:30:36 sean-k-mooney artom: ya the vif you are using in that code is an instance of nova.network.model.Vif https://github.com/openstack/nova/blob/master/nova/network/model.py#L380
16:30:48 sean-k-mooney yes we do
16:31:28 sean-k-mooney but if you wanted to add a flag so you did not check bot of those you could add a property to that class that return a vlaue base on if ether of the dict values were set
16:32:46 sean-k-mooney e.g. put the logic to wait into the Vif class and have a property "wait_location" that return "driver" or "manager" based on the vnic_type or hybrid_plug
16:32:59 sean-k-mooney artom: like https://github.com/openstack/nova/blob/master/nova/network/model.py#L461
16:33:14 sean-k-mooney i guess it could be just a fuction too
16:33:23 aspiers efried: according to the SEV spec, our current plan is to add hw:mem_encryption to flavor extra specs and image properties, but I've just noticed that while existing extra specs params use the "hw:" prefix, image properties all use the "hw_" prefix. Presumably I should remain consistent with those conventions?
16:33:51 artom sean-k-mooney, not sure about putting logic in the model itself, but yeah, it's an idea
16:34:07 mriedem sean-k-mooney: so as it stands, artom's patch will do:
16:34:19 mriedem 1. if all ports are ovs_hybrid_plug=True, wait for all in the manager and you're fine,
16:34:19 sean-k-mooney artom: well we have is_hybrid_plug_enabled in the Vif object
16:34:24 artom 0. drive artom to even moar excessive alcoholism
16:34:35 mriedem 2. if all ports are ovs_hybrid_plug=false, wait in the driver and you're fine (tested in the gate),
16:34:39 artom sean-k-mooney, yeah, but that's basically just a getter
16:35:07 mriedem 3. if some ports are ovs_hybrid_plug=True but not all, we'll wait for all events for all ports in the manager and some might not come (at least direct-physical)
16:35:24 sean-k-mooney mriedem: correctr
16:35:40 mriedem ok so based on #3,
16:36:04 mriedem what if we only wait for the known ones in the manager (ovs_hyrbid_plug=True),
16:36:26 sean-k-mooney direct-pysical will be the same as ovs_hyrbid_plug=True
16:36:35 mriedem and if there are others, we pass vifs_already_plugged=False to the driver? that would fail in the ovs_hybrid_plug=true ports b/c we already processed that event yeah?
16:36:58 sean-k-mooney vnic_type=direct and macvatap are teh same as ovs_hyrbid_plug=False and will arrive at the dirver
16:37:51 sean-k-mooney mriedem: yes it would fail for ovs_hyrbid_plug=True because we already processed it
16:37:57 mriedem i'm trying to get at some best effort kind of logic if we don't have good enough details from neutron and when we get the events from neutron is inconsistent per backend (which we know it is)
16:38:45 mriedem thinking like, compute manager waits for all that are ovs_hybrid_plug=True and if there are others (a mix), we pass vifs_already_plugged=True so the driver doesn't wait
16:38:47 sean-k-mooney if we get a mix we could just not wait at all or wait wait for the ones we expect in the manager and not wait in the driver
16:38:55 mriedem yup i just said the same
16:39:02 sean-k-mooney ya that would work
16:39:15 sean-k-mooney its technically racy but its better then what we have today
16:39:36 sean-k-mooney but i also think it would be simple to have the driver check if it should wait per vif
16:39:41 mriedem in the #2 case where none of the ports are ovs_hybrid_plug=True, we'd pass vifs_already_plugged=false to the driver and assume the driver will wait and get all of the events after it plugs
16:39:44 sean-k-mooney instead of needing to set teh flag
16:39:55 sean-k-mooney yep
16:40:23 sean-k-mooney 1 and 2 are easy
16:40:57 openstackgerrit Eric Fried proposed openstack/nova master: Defaults missing group_policy to 'none' https://review.opendev.org/657796
16:41:02 sean-k-mooney but we really shoudl be checking "ovs_hyrbid_plug=True or vnic_type=direct-physical"
16:41:16 mriedem how many different types of vifs are in the wild?
16:41:34 sean-k-mooney technically its a finite set defiend in neutron lib
16:41:49 sean-k-mooney but not all backend will treat them all the same
16:41:52 mriedem i just kind of vomit in my mouth a bit when we try encoding this in nova
16:41:59 efried aspiers: Yes
16:42:08 sean-k-mooney mriedem: ya i know it sucks
16:42:09 artom mriedem, we really shouldn't have to in theory
16:42:18 artom But reality and all that
16:42:22 efried aspiers: And if you're collecting a spec tweak fup patch, clarify in there.
16:42:55 sean-k-mooney for what its worth however i think we can encode it here in a new 3 line function https://github.com/openstack/nova/blob/master/nova/network/model.py#L461
16:43:21 artom sean-k-mooney, yeah, that part's not hard
16:43:43 artom It's how we use it that I'm fuzzier on
16:43:55 artom Ie, split events to be waited for between compute and libvirt
16:44:26 artom I'm making an executing decision: ph00d, then hax. A patch, even broken WIP, is better than endless discussion
16:44:28 mriedem i'm not terribly comfortable in backporting something that gets this complicated especially since we don't test any of these vif types in the gate
16:44:34 sean-k-mooney e.g. def wait_in_manager(self):
16:44:36 sean-k-mooney retrun self.is_hybrid_plug_enabled or self.get("vnic_type") == "direct-physical"
16:45:00 mriedem artom: hacking something up that you do'nt have agreement on from the people reviewing it isn't going to speed this up
16:45:11 sean-k-mooney then in the manager an driver we just do if vif.wait_in_manager():
16:45:13 artom mriedem, I thought we kinda did?
16:45:27 mriedem how about, 1. artom gets food, 2. sean comments on the change
16:45:30 artom mriedem, for backporting, if we split the patch and only backport the hybrid stuff?
16:45:30 mriedem 3. artom digests both
16:45:41 artom Leaving the SRIOV stuff for master only
16:46:37 sean-k-mooney artom: or we can backport this downstream only if we really have to
16:46:54 sean-k-mooney but ill comment on the review i think we can make this simpler
16:46:57 artom sean-k-mooney, it's always an option, but not my first one, obviously
16:47:22 sean-k-mooney i think if we only fix it for ovs we will get a bug report form a different custoemr for sriov
16:47:25 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Document how to revert, confirm a cold migration https://review.opendev.org/664396
16:47:33 sean-k-mooney so we will have to fix both eventually
16:47:42 artom sean-k-mooney, yeah, and that's fine, and we can address it later
16:47:56 artom Especially since it'd be as simple as adding a check to that 3-line method of yours :)
16:48:27 artom We could even do it now in a fup patch, and backport if/when some testing happens
16:48:31 sean-k-mooney its actully 2 lines :P untill we have pep8 it
16:48:32 artom *fup patch now
16:49:02 artom (Though realistically it shouldn't merge until if/when some testing happens :)
17:02:46 openstackgerrit Matt Riedemann proposed openstack/nova master: Deprecate RetryFilter https://review.opendev.org/663953
17:06:01 openstackgerrit Adam Spiers proposed openstack/nova-specs master: Change new image property to hw_mem_encryption https://review.opendev.org/664397
17:26:37 aspiers efried: should I hold off including doc change fragments covering SEV support until the whole series lands?
17:27:12 efried aspiers: "doc change fragments" in the spec or in the codebase?
17:27:17 aspiers codebase
17:27:20 aspiers otherwise there's a risk of documenting stuff which doesn't work yet
17:27:26 aspiers especially if it didn't all land before Train
17:27:37 efried Right, those go in in the patch that flips the switch that makes it work.
17:27:45 aspiers OK thanks
17:27:46 efried docs & reno etc.
17:27:49 aspiers Yup
17:45:53 spatel sean-k-mooney: is there anyway to stop migration instance? I have initiate block migration and i want to cancel it
17:46:21 sean-k-mooney spatel: as in cancel a livemigration
17:46:26 sean-k-mooney i think we have a way too
17:46:31 sean-k-mooney let me check
17:46:38 sean-k-mooney i know people have asked for it before
17:46:44 spatel i didn't find any command line option or GUI option
17:47:16 sean-k-mooney well what you can do with crul directly to the api is > then the clis enable
17:47:30 sean-k-mooney i dont know if we ever landed the force complete and force abourt apis however

Earlier   Later