| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-10 | |||
| 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 | mriedem | 3. artom digests both | |
| 16:45:30 | artom | mriedem, for backporting, if we split the patch and only backport the hybrid stuff? | |
| 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> | |
| 17:58:32 | sean-k-mooney | to see which one was the most recent | |
| 17:58:42 | sean-k-mooney | and then that one is the migration you want to canchel with | |
| 17:58:53 | sean-k-mooney | nova live-migration-abort INSTANCE_ID MIGRATION_ID | |
| 18:00:02 | spatel | nova server-migration-list <server id> this is showing nothing about migration except saying | OS-EXT-STS:task_state | resize_migrating | |
| 18:00:36 | spatel | i am not seeing any ID... | |