| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-21 | |||
| 22:11:30 | dansmith | melwitt: okay, I just read your comment but I didn't go look at the (old) code to see, but.. sounds good? :) | |
| 22:11:52 | melwitt | dansmith: yeah, just chattering aloud. I'm excited that this makes sense now | |
| 22:12:28 | dansmith | melwitt: I will put a dan dummy in my chair who will continue to listen to your chattering. he doesn't type though, so just assume he's saying "uh huh, yeah, oh. sounds good. uh huh, yeah..." | |
| 22:12:47 | melwitt | haha | |
| 22:13:03 | dansmith | mriedem: and no snide comments from you mister. | |
| 22:13:42 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.openstack.org/555081 | |
| 22:15:51 | mikal | pick me pick me! | |
| 22:15:59 | mriedem | i'd have to see the proposed fix | |
| 22:16:01 | mikal | Basically snide comments is all I do now. | |
| 22:17:36 | melwitt | Snide Comment Czar | |
| 22:17:38 | mriedem | melwitt: so you want to move this call to _make_instance_list from here https://github.com/openstack/nova/blob/9465d1c/nova/objects/instance.py#L1235 to right after _get_by_filters_impl is called here https://github.com/openstack/nova/blob/9465d1c/nova/objects/instance.py#L1243 ? | |
| 22:17:51 | mikal | I would accept that job | |
| 22:18:01 | mikal | Or anything entitled "Old man shakes fist at clouds" | |
| 22:18:04 | melwitt | mriedem: yeah, that's what I'm trying right now. already have the func test written. let's see if it works | |
| 22:19:56 | melwitt | yay | |
| 22:23:50 | mriedem | so why couldn't we just also make this change on master and backport it? | |
| 22:24:01 | mriedem | even if it's not a problem on master, | |
| 22:24:06 | mriedem | would changing the same code cause any problems? | |
| 22:24:50 | melwitt | oh yeah, that's a better idea actually | |
| 22:25:08 | melwitt | when I first asked, I wasn't thinking the code was going to be the same on master but it is | |
| 22:26:15 | mriedem | dansmith: it would be best if your dan dummy looked like https://www.youtube.com/watch?v=_WQfZYacEAw | |
| 22:26:20 | melwitt | I'll have to rewrite this func test a bit to be a regression func test that will still fail on master. not a big deal | |
| 22:26:44 | mriedem | melwitt: writing a test on master to fail for a thing that doesn't fail on master...breaks my brain | |
| 22:26:44 | dansmith | mriedem: what else would it look like? | |
| 22:27:10 | mriedem | unless you're not going to reproduce it through the API | |
| 22:27:22 | mriedem | but just through the object methods directly | |
| 22:27:36 | melwitt | mriedem: sorry, it will fail on master in an artificial scenario that isn't currently being run. yeah, I don't think I can reproduce it through the API, from what I've seen so far | |
| 22:27:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: List instances performace optimization https://review.openstack.org/507854 | |
| 22:28:07 | melwitt | but calling InstanceList.get_by_filters with expected_attrs=['services'] with a service record with no uuid should do it | |
| 22:28:20 | mriedem | that'd be fine then | |
| 22:28:31 | melwitt | k, doing | |
| 22:28:49 | mriedem | i'd like to note that i can't remember the last time i've had so many "is this appropriate for stable" conversations in the same week | |
| 22:29:04 | melwitt | Stable Czar | |
| 22:29:19 | mriedem | i would like to avoid the term "czar" for anything | |
| 22:29:25 | mriedem | or tsar | |
| 22:29:27 | melwitt | yeah, good point | |
| 22:29:28 | mriedem | or caesar | |
| 22:30:08 | mriedem | isn't the point of czar kind of that there is only one anyway... | |
| 22:30:30 | melwitt | I dunno. years ago there was a czar for everything and I was thinking back to that | |
| 22:30:44 | mriedem | i got the reference, i just never liked that | |
| 22:30:58 | mriedem | https://wiki.openstack.org/wiki/Nova#People | |
| 22:31:35 | melwitt | yeah, same. I guess it stuck in my brain though | |
| 22:31:43 | dansmith | mriedem is the sarcasm czar whether he likes it or not | |
| 22:31:48 | dansmith | sorry mikal | |
| 22:34:30 | mriedem | cfriesen: heh https://bugs.launchpad.net/nova/+bug/1754782 | |
| 22:34:31 | openstack | Launchpad bug 1754782 in OpenStack Compute (nova) "we skip critical scheduler filters when forcing the host on instance boot" [Undecided,Opinion] | |
| 22:34:39 | mriedem | "nova put the instance on the host where i told it to" | |
| 22:35:15 | mriedem | cfriesen: if you haven't realized it yet, the RUN_ON_BUILD = True thing is not something we enjoy having in the scheduler | |
| 22:35:22 | mriedem | *RUN_ON_REBUILD | |
| 22:35:44 | mriedem | also, remember the -5 to forcing a host during cold migration | |
| 22:35:57 | cfriesen | mriedem: so why don't we just run all the filters and only evaluate the specified hostname? | |
| 22:36:30 | cfriesen | other than "because that's how we've always done it" | |
| 22:36:45 | mriedem | ask bauzas | |
| 22:37:04 | mriedem | he talks at least semi-annually about changing the forst host/node stuff in server create to be a 'requested' destination | |
| 22:37:19 | mriedem | evaluated by the scheduler | |
| 22:37:20 | cfriesen | do it | |
| 22:37:21 | cfriesen | ;) | |
| 22:37:34 | mriedem | that would be a microversion of course | |
| 22:37:52 | mriedem | which i'd be ok with, it would be like passing a host to evacuate or live migrate | |
| 22:37:56 | mriedem | and cold migrate now i guess | |
| 22:38:22 | cfriesen | did we do a microversion when we started prefiltering via placement when forcing the destination? | |
| 22:39:09 | cfriesen | I guess it's the claim in placement that I mean, not the prefiltering | |
| 22:41:42 | mriedem | no, but i don't buy that argument | |
| 22:41:50 | mriedem | i believe you could still fail the claim in the compute even if you force | |
| 22:42:27 | mriedem | but i might be wrong, as i think the filters add the limits to the dict that gets passed down from scheduler to compute | |
| 22:43:10 | mriedem | anyway, we have to claim in placement (Create the allocations) otherwise our tracking gets all screwed up, so i don't feel bad about breaking the 'force host' contract there | |
| 22:43:56 | cfriesen | I think the limits happen after the filters...but in any case I get that we don't want to change behaviour without a microversion even if we never really defined the behaviour. | |
| 22:44:23 | mriedem | the limits dict is passed from the scheduler down through conductor to the compute | |
| 22:44:25 | mriedem | and used for the claim | |
| 22:44:34 | mriedem | the limits dict in the scheduler is i believe populated via the filters | |
| 22:45:03 | mriedem | which is why we can't remove the old school claim stuff in compute until we at least drop something like the caching scheduler, which doesn't use placement and relies on the late ass claim | |
| 22:46:49 | cfriesen | I think you're right...I see the filters updating host_state.limits | |
| 22:46:56 | mriedem | guh, i've triaged at least 2 bugs like this today https://bugs.launchpad.net/nova/+bug/1754543 | |
| 22:46:57 | openstack | Launchpad bug 1754543 in OpenStack Compute (nova) "not update request_spec.request_networks after attach or detach interface" [Undecided,Invalid] - Assigned to Deepak Mourya (mourya007) | |
| 22:47:06 | mriedem | "request spec isn't what i expect it to be" | |
| 22:47:21 | mriedem | how is that a bug, except for wanting to hack in your own private stuff | |
| 22:51:32 | cfriesen | heh...so they want request spec to reflect the instance as it is now, rather than as it was at boot time? | |
| 22:51:53 | sean-k-mooney[m] | mriedem: i havent read it yet but i would expect the request spec in the instance to be updated when i attach or detach an interface so livemigration would work right | |
| 22:52:23 | mriedem | cfriesen: i guess | |
| 22:52:38 | mriedem | sean-k-mooney[m]: we already have a thing that tracks that, | |
| 22:52:40 | mriedem | it's called, | |
| 22:52:43 | mriedem | the instance | |
| 22:53:06 | mriedem | the request spec is not in the instance | |
| 22:53:16 | mriedem | it's a copy of the initial server create request | |
| 22:53:19 | cfriesen | mriedem: don't we feed the request spec to the scheduler when searching for a dest? | |
| 22:53:26 | mriedem | minus ports and bdms | |
| 22:53:38 | mriedem | cfriesen: sure do | |
| 22:53:42 | mriedem | sometimes slightly modified | |
| 22:53:58 | mriedem | so my guess would be, people have out of tree filters, | |
| 22:54:06 | mriedem | and those filters need to know information about volumes and ports on the instance, | |
| 22:54:13 | mriedem | and they want to get it from the request spec, | |
| 22:54:20 | cfriesen | I was going to ask about ports/bdms, but then you pointed out that they were subtracted anyways. | |
| 22:54:23 | mriedem | because they are too lazy to hit the DB, or cinder or neutron APIs | |
| 22:54:37 | mriedem | they aren't subtracted, they just aren't persisted in the request spec | |
| 22:54:43 | sean-k-mooney[m] | mriedem: well if we send the request spec to the schduler when livemigrating then would you not want it to have the list of networks you vm currently has instead of the inital set | |
| 22:55:08 | mriedem | sean-k-mooney[m]: we don't have any filters that look at that | |
| 22:55:35 | mriedem | "nova doesn't provide the thing my private out of tree filter needs" isn't a bug | |
| 22:56:14 | sean-k-mooney[m] | the pci passthrough fileter looks at this | |
| 22:56:37 | sean-k-mooney[m] | that said i guess we dont supprot hot attach for sriov interfaces currently | |
| 22:56:54 | sean-k-mooney[m] | you can detach actully but just not attach | |