Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-24
10:19:27 bauzas I mean, the filter scheduler returns compute nodes
10:19:34 bauzas the host manager returns host states
10:19:34 johnthetubaguy bauzas: I kinda like passing the spec_obj into the placement client
10:19:43 bauzas that, I'm not sure
10:20:06 johnthetubaguy ah, OK, you want that to be resource providers?
10:20:07 johnthetubaguy thats fair enough
10:20:15 bauzas johnthetubaguy: because I'd like to see the "spec to RC usage" logic be still a scheduler thing
10:20:38 bauzas the placement client shouldn't expect anything about how the scheduler works
10:21:03 mdbooth johnthetubaguy pkoniszewski: Sorry, even though I only read it yesterday, I still had to refresh it :)
10:21:05 gmann alex_xu: for bdm yes as there is no additionalProperties=False there but yes for network it is not allowed as additionalProperties=False :(
10:21:15 bauzas johnthetubaguy: in particular given I'm now very opiniated on having the resource query being optional depending on the filters
10:21:30 gmann alex_xu: i am modifying tempest device tag tests with all combination and with all version mentioned by you
10:21:39 mdbooth So there's live_migration_downtime, which is the maximum permitted downtime of an instance during live migration
10:21:41 gmann alex_xu: let's see how bdm tag behave on those
10:21:42 bauzas johnthetubaguy: the last 3 days convinced me we need to opt-in the filters
10:22:10 johnthetubaguy mdbooth: totally with you on need to refresh, I guess thats the problem the operators are having too
10:22:16 mdbooth Then there live_migration_downtime_steps, which is the number of steps to take towards that maximum, and live_migration_downtime_delay, which is the delay between each step.
10:22:17 bauzas johnthetubaguy: either way, thanks for reviewing, that's very good insight, and I can do a new iteration this morning
10:22:35 bauzas johnthetubaguy: FWIW, I'm stuck with grenade not liking the placement service in newton
10:22:49 johnthetubaguy bauzas: I was thinking it would ideally be an object we pass into the placement client (that could be empty)
10:22:51 mdbooth So the total time until we go with the maximum is live_migration_downtime_steps * live_migration_downtime_delay
10:22:58 mdbooth pkoniszewski: Am I reading that right? ^^^
10:22:59 johnthetubaguy bauzas: ah yeah, that... :(
10:22:59 alex_xu gmann: initial I also think there is no addtionalProperties, but I found it copy that from bdm v1 schema https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/block_device_mapping.py#L61
10:23:13 pkoniszewski johnthetubaguy: but im still considering a new config option, i see a case where operator might want to get to target downtime in a couple of seconds but still such live migration might need 10+ minutes to complete
10:23:16 bauzas johnthetubaguy: for the moment, I was seeing a dict
10:23:22 pkoniszewski mdbooth: right, that's the current state
10:23:27 bauzas johnthetubaguy: but longer term, why not an object, agreed
10:23:53 johnthetubaguy bauzas: honestly, a TODO in there saying this argument sucks might be all I need on that bit, lol
10:23:57 bauzas I'm just thinking it shouldn't be the Spec object
10:24:11 openstackgerrit Andrey Kurilin proposed openstack/python-novaclient: [CLI] Fix token auth type https://review.openstack.org/424256
10:24:12 johnthetubaguy bauzas: yeah, thats cool, I just re-read that file, it has to be resource providers
10:24:18 bauzas yup zactly
10:24:24 gmann alex_xu: ahh, yea, thanks for pointing that
10:24:42 bauzas and the scheduler has some internal logic for translating the Spec object into a ResourceProviderQuery object
10:24:48 mdbooth pkoniszewski: My idea just was to add a new option which is the total time, hardcode the number of steps to 10 as you've done, and default the total to the product of the set deprecated values (if they're set).
10:24:55 bauzas whatever the object is
10:24:58 johnthetubaguy bauzas: so maybe if you pass the return value of placement into host_manger get, even if thats just the list of uuids, that would be better
10:24:59 alex_xu gmann: np, I drop in that trap also :)
10:25:02 johnthetubaguy bauzas: yeah, that sounds good
10:25:12 johnthetubaguy bauzas: right now its a dict, but thats OK for now I guess
10:25:18 bauzas johnthetubaguy: I can forge a patch soon
10:25:29 mdbooth pkoniszewski: Incidentally, I also wonderered about setting guest.migrate_configure_max_downtime() on every iteration, regardless of steps.
10:25:35 mdbooth Would that be expensive?
10:25:36 bauzas johnthetubaguy: and I'll wait for sean about how to discuss the grenade thing
10:25:58 bauzas because the issue I guess is that we don't default running the placement service in newton
10:26:11 johnthetubaguy bauzas: cool, hopefully that helps, just didn't quite read as I expected
10:26:13 gmann alex_xu: heh
10:26:14 bauzas so, when upgrading, it fails because the config file is not correctly setup
10:26:42 bauzas that would suppose we would modify the config between newton and ocata, but that's pretty high impacty
10:27:01 johnthetubaguy bauzas: honestly, we might just need to support not having placement while the min_service_version is below a threshold, and only start using it after that point?
10:27:20 bauzas johnthetubaguy: that's why I'm waiting the US folks to be up before engaging that convo
10:27:22 bauzas :)
10:27:43 bauzas lots of discussions went already around about the upgrade path
10:27:50 johnthetubaguy mdbooth: we still need something that sets QEMU occasionally on some periodic task, but thats a good point, you can just work out where you should be on the line, and set that value
10:28:07 johnthetubaguy bauzas: yeah
10:28:22 johnthetubaguy bauzas: just curious why we don't do it the usual way, but thats for later
10:28:38 bauzas johnthetubaguy: meaning be gentle with not having the placement service for newton ?
10:28:58 bauzas and gracefully fallback if we don't have the version supported ?
10:29:23 bauzas that's one option but the consensus was that it was okay to have a maintenance window
10:29:51 johnthetubaguy bauzas: well its not really a maintenance window right, its just if you want no outage, you have to do more work
10:33:04 openstackgerrit Radomir Dopieralski proposed openstack/python-novaclient: ListExtResource given in place of ListExtManager https://review.openstack.org/424570
10:38:23 bauzas johnthetubaguy: tried to summarize our convo in https://review.openstack.org/#/c/417961/19/nova/scheduler/client/report.py@212, just drop a note if you think I misunderstood our agreement
10:38:34 bauzas meanwhile, writing a new iteration
10:38:34 gmann alex_xu: johnthetubaguy oomichi additionalProperties=False saved us many times but this we only got under its hammer :)
10:38:49 gmann *this time
10:41:19 johnthetubaguy bauzas: we would pass resource providers uuids into the host manager I guess?
10:41:24 openstackgerrit Huan Xie proposed openstack/nova: Fix live migrate with XenServer https://review.openstack.org/424428
10:42:25 bauzas johnthetubaguy: I'm not opiniated on that
10:42:30 bauzas johnthetubaguy: that's fine to me
10:42:48 bauzas because a RP uuid is the compute uuid
10:42:51 johnthetubaguy bauzas: me neither, that just seems simplest at the moment
10:42:54 bauzas so I'd name it compute_uuids
10:43:16 bauzas just to make it clear that I'd never name something related to resource providers into the host manager
10:43:33 bauzas the hostmanager only knows hosts and returns host states
10:43:42 bauzas hence why I think you made an excellent and valid comment
10:43:52 bauzas because my current proposal sucked
10:44:12 johnthetubaguy bauzas: it wasn't that bad, but yeah, that sounds worth a try
10:44:25 bauzas johnthetubaguy: it was poorly designed, if you prefer
10:44:54 johnthetubaguy a class was operating on multiple levels of abstractions, causing some confusion, or something like that
10:45:10 bauzas the exact reason why I haven't yet written UTs :)
10:45:27 bauzas because I needed kind of an agreement on the interfaces before moving on
10:46:14 openstackgerrit Balazs Gibizer proposed openstack/nova: Fix race condition in instance.update sample test https://review.openstack.org/424574
10:47:43 BobBall johnthetubaguy: https://bugs.launchpad.net/nova/+bug/1658877 - found a bug which prevents all XAPI live migrations and we'd really appreciate your input on it.
10:47:43 openstack Launchpad bug 1658877 in OpenStack Compute (nova) "live migration failed with XenServer as hypervisor" [Undecided,In progress] - Assigned to huan (huan-xie)
10:48:31 johnthetubaguy BobBall: I think I saw that patch pass by, will take a peak
10:48:45 BobBall Awesome, thanks.
10:49:30 johnthetubaguy BobBall: why did it work before without the vif mappings there?
10:50:07 openstackgerrit Matthew Booth proposed openstack/nova: libvirt: Fix races in glusterfs mount/umount https://review.openstack.org/423402
10:51:05 BobBall johnthetubaguy: The addition of the interim network to fix the neutron vlan tagging on vif/tap bug (and also to support neutron security groups) introduces a per-VIF network. The per-VIF network doesn't exist (by name) on the destination and therefore XAPI can no longer make a good guess for what the vif mapping should be.
10:51:43 johnthetubaguy BobBall: that would totally do it
10:52:09 BobBall johnthetubaguy: Indeed :(
10:53:20 johnthetubaguy BobBall: this isn't backportable, because of the object version stuff
10:53:29 johnthetubaguy as a heads up
10:54:02 BobBall Understood. I am trying to also understand whether we actually need to pass the mapping back; if we create a network with the same name on the target wouldn't XAPI just do the right thing(tm)?
10:54:21 BobBall Anyway - I'll put review comments in the code. Just wanted to highlight it for you as a heads up.
10:57:23 johnthetubaguy BobBall: why is the vif thing only used for VM.migrate_send?
10:57:36 johnthetubaguy BobBall: is it not accepted by the other call?
10:58:19 BobBall johnthetubaguy: Not needed for sure - it would probably be ignored if it was present.
10:58:32 BobBall johnthetubaguy: Good comment though, we can check the API to be sure.

Earlier   Later