| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-21 | |||
| 22:08:01 | melwitt | is it cool if I propose a fix only for pike? how does that usually work? | |
| 22:08:44 | dansmith | melwitt: ah yeah that sort of nesting is exactly what I was saying would have to happen, but was skeptical of it existing | |
| 22:08:54 | dansmith | melwitt: so.. glad you traced it all the way down :) | |
| 22:09:05 | cfriesen | mriedem: what about this? https://bugs.launchpad.net/nova/+bug/1552777 | |
| 22:09:07 | dansmith | melwitt: mriedem would know better than me, but we've had to do that before, IIRC | |
| 22:09:07 | openstack | Launchpad bug 1552777 in OpenStack Compute (nova) "resizing from flavor with swap to one without swap puts instance into Error status" [Medium,In progress] - Assigned to Kam Nasim (knasim-wrs) | |
| 22:09:20 | mriedem | reminds me of https://review.openstack.org/#/c/507854/ | |
| 22:10:07 | cfriesen | mriedem: though it looks like that one went away in pike | |
| 22:10:43 | sean-k-mooney[m] | Cfriesen resize with swap is picky. I think it works more or less now | |
| 22:10:50 | melwitt | dansmith: yeah, initially I couldn't repro it (as expected) with only a service query. but yeah, got to the bottom of it :) I think it could be easily fixed by just splitting the _make_instance_list call out from under the _get_by_filters_impl, that is, move it to get_by_filters | |
| 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 | dansmith | mriedem: what else would it look like? | |
| 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: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, | |