| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-24 | |||
| 10:18:47 | bauzas | johnthetubaguy: what I'm saying is that the translation from RP to compute nodes should still be filter scheduler thing | |
| 10:18:59 | johnthetubaguy | bauzas: agreed | |
| 10:19:14 | johnthetubaguy | bauzas: I think the filter scheduler method stays the same, its just whats in there that changes | |
| 10:19:15 | bauzas | johnthetubaguy: from an interface PoV, that's actually an excellent point | |
| 10:19:27 | bauzas | I mean, the filter scheduler returns compute nodes | |
| 10:19:34 | johnthetubaguy | bauzas: I kinda like passing the spec_obj into the placement client | |
| 10:19:34 | bauzas | the host manager returns host states | |
| 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 | 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:22:59 | johnthetubaguy | bauzas: ah yeah, that... :( | |
| 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 | gmann | alex_xu: johnthetubaguy oomichi additionalProperties=False saved us many times but this we only got under its hammer :) | |
| 10:38:34 | bauzas | meanwhile, writing a new iteration | |
| 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 | openstack | Launchpad bug 1658877 in OpenStack Compute (nova) "live migration failed with XenServer as hypervisor" [Undecided,In progress] - Assigned to huan (huan-xie) | |
| 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: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. | |