Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-10
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
17:47:32 spatel ?
17:48:05 sean-k-mooney we dont always get around to adding everyting that the api support to the command line clients
17:48:13 sean-k-mooney or somethimes it takes a while
17:49:33 spatel what if i kill TCP connection which is transferring disk
17:49:57 sean-k-mooney spatel: you can abort it via libvirt using virsh
17:50:58 sean-k-mooney spatel: so ya it looke like you can use the old nova cli
17:51:11 sean-k-mooney nova live-migration-abort INSTANCE_ID MIGRATION_ID or nova live-migration-force-complete INSTANCE_ID MIGRATION_ID
17:51:31 sean-k-mooney spatel: https://docs.openstack.org/nova/pike/admin/live-migration-usage.html#addressing-migration-timeouts
17:52:34 sean-k-mooney spatel: nova live-migration-abort is what you are looking for.
17:52:54 spatel let me see
17:52:55 sean-k-mooney you need the instance id + the migration_id for the currently running migration
17:53:26 sean-k-mooney you get the migration id by doing "nova server-migration-list <server/instance uuid>"
17:54:10 spatel how do i find MIGRATION_ID?
17:54:25 sean-k-mooney spatel: ^ :)
17:54:58 sean-k-mooney spatel: its covered in the monitoring migration part of that doc https://docs.openstack.org/nova/pike/admin/live-migration-usage.html#monitoring-the-migration
17:55:08 spatel reading it..
17:57:26 sean-k-mooney does that make sense you do "nova server-migration-list <server id>"
17:57:38 sean-k-mooney then that give you the list of migrations.
17:58:20 sean-k-mooney then if you have more then one you use nova server-migration-show <server uuid > <migration id>

Earlier   Later