Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-10
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
16:16:54 sean-k-mooney if the the prot is a PF https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_sriov/mech_driver/mech_driver.py#L163-L168
16:17:03 sean-k-mooney we will send the event when we update the binding
16:17:16 sean-k-mooney if the port if a vf we will send the event when the agent wires it up
16:18:04 artom At point do we just say screw it and start queuing reveived events?
16:18:09 artom *At what
16:18:27 artom Or unload all those problems on Neutron and tell them to send the events consistently?
16:19:13 sean-k-mooney well https://review.opendev.org/#/c/645173/ is ment to help with this
16:19:22 artom Because assuming what sean-k-mooney is saying is True (and I have no reason to doubt it, but it def needs testing), we now have 3 different port "types" that we need to be aware of
16:19:40 sean-k-mooney but i have not been working on it because of other stuff like RDT/CAT
16:20:53 artom sean-k-mooney, yeah, but depending on that spec would make the Nova patch unbackportable, which I'm trying to avoid
16:21:03 artom (Never mind that it would take forever
16:21:05 artom )
16:21:53 sean-k-mooney right also i have not had time to work on it for a month and likely wont in the short term as i have nto figured out how to expresss when the event will be sent yet in an abstct way

Earlier   Later