| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-10 | |||
| 14:56:19 | stephenfin | Seriously? Why can't I find any documentation on the internet about this? | |
| 14:56:34 | sean-k-mooney | because its an internal detail of nova implemeation | |
| 14:56:48 | sean-k-mooney | it should be in a dev ref | |
| 14:56:55 | stephenfin | The ability of a user to revert their failed cold migration is a internal detail? | |
| 14:57:07 | stephenfin | How it's implemented, sure, but not the raw ability to do the thing | |
| 14:57:09 | sean-k-mooney | its in the api ref | |
| 14:57:10 | mriedem | for one, users don't cold migrate, admins do | |
| 14:57:22 | mriedem | https://developer.openstack.org/api-ref/compute/?expanded=migrate-server-migrate-action-detail#migrate-server-migrate-action | |
| 14:57:40 | mriedem | "after a successful cold migration and then must be confirmed or reverted." | |
| 14:58:37 | stephenfin | the more you know | |
| 14:58:39 | sean-k-mooney | i think revert does not require admin https://developer.openstack.org/api-ref/compute/?expanded=migrate-server-migrate-action-detail,revert-resized-server-revertresize-action-detail#migrate-server-migrate-action | |
| 14:58:52 | sean-k-mooney | except as indicated in teh precondions | |
| 14:58:53 | mriedem | "Policy defaults enable only users with the administrative role to perform this operation. " | |
| 14:59:01 | mriedem | cold migrate is admin_api by default | |
| 14:59:15 | stephenfin | Hmm, why don't we have an 'openstack server migrate --revert' thing for this? | |
| 14:59:24 | mriedem | we do | |
| 14:59:44 | mriedem | https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#server-resize | |
| 14:59:46 | mriedem | resize --revert | |
| 15:00:01 | stephenfin | that's 'resize --revert', not 'migrate --revert' | |
| 15:00:15 | mriedem | they hit the same api | |
| 15:00:27 | stephenfin | Then why have an 'openstack migrate' command | |
| 15:00:38 | mriedem | for cold and live migration | |
| 15:00:48 | mriedem | which are not resizes | |
| 15:01:34 | stephenfin | live migration, sure, but not cold migration | |
| 15:01:44 | stephenfin | that's the same thing but with the same image? | |
| 15:01:46 | stephenfin | *flavor | |
| 15:02:06 | sean-k-mooney | stephenfin: we could delete migrate and jsut use resize for the cold migration case but most user dont think a resize and migration are the same thing | |
| 15:02:07 | mriedem | cold migrate == resize but with no flavor change | |
| 15:02:58 | stephenfin | sean-k-mooney: Yeah, that's my point. Why would a user think "oh, my migration failed. Best revert this resize" | |
| 15:03:00 | sean-k-mooney | migrate is just syntactic sugar over resize really. | |
| 15:03:06 | stephenfin | yeah | |
| 15:03:14 | mriedem | note that a revert isn't to recover a failed move | |
| 15:03:25 | mriedem | you can only revert if the resize/cold migration *didn't* fali | |
| 15:03:26 | mriedem | *fail | |
| 15:03:53 | stephenfin | Actually, yeah, I've done this in tests now that I think about | |
| 15:03:54 | stephenfin | *it | |
| 15:04:21 | stephenfin | (Or rather avoided doing it because confirming a resize/migration requires a lot of mocking out of libvirt stuff in functional tests that's not worth the effort) | |
| 15:05:03 | stephenfin | mriedem: I think a '--revert' flag for the 'openstack server migrate' command would be helpful syntactic sugar. Any reason not to? | |
| 15:05:04 | mriedem | if you're concerned about docs, you could update the description on https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#server-migrate to talk about how after a successful cold migration you need to revert or confirm the migration and which commad does that | |
| 15:05:17 | stephenfin | I can do that too, sure | |
| 15:05:39 | mriedem | idk, ask dean. one reason could be someone thinking they could revert a live migration since that's built into the same command. | |
| 15:05:42 | Nick_A | sorry if this is not the right place - we have a kvm compute with qcow2, but snapshots are being stored as raw. is there a setting we're overlooking to take snapshots as qcow2? | |
| 15:05:51 | mriedem | but that's likely solved with a good description of the parameter and validation in the command. | |
| 15:05:54 | stephenfin | I'm annoyed that I work on this stuff and _I_ wasn't able to find information about this easily. That seems...silly :) | |
| 15:06:05 | stephenfin | Yeah, we already have that issue for other flags so this is just one more | |
| 15:06:17 | mriedem | Nick_A: probably this https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.force_raw_images | |
| 15:07:15 | Nick_A | thank you, looking | |
| 15:07:37 | mriedem | Nick_A: I think glance also has an option to convert everything to raw | |
| 15:07:53 | stephenfin | Okay, I'll start on that. Thanks for the clarification, mriedem, sean-k-mooney | |
| 15:08:13 | sean-k-mooney | stephenfin: there are some docs here too https://github.com/openstack/nova/blob/master/doc/source/admin/migration.rst | |
| 15:09:19 | mriedem | Nick_A: I think this https://docs.openstack.org/glance/latest/configuration/glance_api.html#taskflow_executor.conversion_format | |
| 15:09:26 | sean-k-mooney | stephenfin: we show we use "openstack server resize --confrim" to confrim the migration but not how to revert | |
| 15:09:51 | Nick_A | thank you | |
| 15:10:25 | stephenfin | sean-k-mooney: Sweet, I'll fix that too and add some some 'migrate --confirm' syntactic sugar for good measure | |
| 15:15:24 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/stein: Avoid unnecessary joins in InstanceGroup.get_hosts https://review.opendev.org/664271 | |
| 15:40:22 | dansmith | mriedem: are you going to update the pre-filter disabled computes spec? | |
| 15:40:34 | dansmith | I assume gibi is on vacay or something and hasn't circled back, | |
| 15:40:49 | dansmith | but I figure he's probably fine with it as long as we have a plan for that (which we do) | |
| 15:41:11 | mriedem | dansmith: i was waiting for gibi | |
| 15:42:12 | dansmith | okay | |
| 15:43:29 | mriedem | what was the plan again? :) on disable, check if down and if down, return 200 (like if it was an old compute) and let upt sync the trait on restart of the service | |
| 15:44:00 | mriedem | if that's the plan i can write that edge case into the spec | |
| 15:44:01 | dansmith | yeah, always set compute.disabled=True, not make the rpc call if it's down, return 200 | |
| 15:44:29 | mriedem | ok i can wordsmith that after tearing up artom's patch here | |
| 15:44:43 | dansmith | by all means, prioritize tearing up anything of artom's | |
| 15:44:46 | artom | ;_: | |
| 15:45:07 | artom | (That's from both emotional and physical pain) | |
| 15:48:24 | aspiers | stephenfin: ok to add you to reviewers for a couple of SEV patches which need more core attention? they're not particularly big or complex | |
| 15:48:31 | stephenfin | sure | |
| 15:48:35 | aspiers | thanks! | |
| 16:00:48 | mriedem | artom: sean-k-mooney: mdbooth: dansmith: comments in https://review.opendev.org/#/c/644881/ | |
| 16:01:18 | artom | Whoa, you weren't kidding about tearing up | |
| 16:01:37 | mdbooth | Whoa! | |
| 16:01:43 | mdbooth | mriedem: Thanks, btw | |
| 16:02:33 | artom | sean-k-mooney, correct me if I'm wrong, but I don't believe "The bigger issue I have is the concern that we could have a server with both ovs hybrid plugged ports and ports without that" is possible | |
| 16:03:16 | sean-k-mooney | it is only posible if you have ovs +sriov ports | |
| 16:03:43 | sean-k-mooney | e.g. if they are all ovs ports then it would all be hybrid_plug true or false | |
| 16:03:59 | artom | sean-k-mooney, ah, so ports on which the firewall driver that causes hybrid plug to be used doens't apply | |
| 16:04:08 | sean-k-mooney | but if you have some vswitch prot for say managmenet and some sriov ports for the data plane then you could have a mixx | |
| 16:04:10 | artom | (https://review.opendev.org/#/c/660782/6/playbooks/legacy/nova-multinode/run.yaml@55) | |
| 16:06:16 | sean-k-mooney | right so if you are using sriov there is no firewall | |
| 16:06:18 | artom | So... do we need to handle that? Ie, wait for hybrid plugged ports in the compute manager, and for the sriov ones in the virt driver? | |
| 16:06:43 | artom | Or is there no vif to plug for the latter case, so it's irrelevant? | |
| 16:07:19 | mriedem | or will you get an event regardless b/c of the port binding change, in which case you don't need to filter on ovs hybrid plug in the compute manager | |
| 16:07:20 | sean-k-mooney | that is a good question there should be a vif plugged in that case | |
| 16:07:24 | sean-k-mooney | so i guess we would | |
| 16:07:54 | mriedem | which would take this change back to when artom, dansmith and i talked about it on hangouts 2 months ago | |
| 16:09:54 | sean-k-mooney | we would get an event for the sriov port | |
| 16:09:58 | artom | *sigh* | |
| 16:10:10 | artom | I suppose we better test it | |
| 16:10:20 | sean-k-mooney | but im trying to remeber when | |
| 16:10:49 | sean-k-mooney | plug is a noop for sriov. it is handeled by libvirt. | |
| 16:11:10 | artom | Actually, wait | |
| 16:11:27 | artom | Is resizing an instance with SRIOV supported? | |
| 16:11:30 | sean-k-mooney | yes | |
| 16:11:41 | sean-k-mooney | its kind of buggy but yes | |
| 16:12:45 | sean-k-mooney | althogh https://review.opendev.org/#/q/topic:bug/1809095+(status:open+OR+status:merged) will fix the most recent one | |
| 16:16:08 | sean-k-mooney | this is concerning https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_sriov/mech_driver/mech_driver.py#L131-L143 | |
| 16:16:32 | artom | I suppose I could hax _get_neutron_events_for_migration() to be smart about what vifs it returns... | |
| 16:16:52 | artom | That seems fragile as hell, event more than the patch in its current form | |