| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-21 | |||
| 17:58:21 | artom | So anything involving flavor extra specs isn't policy then - ie, no need to check with it on rebuild, it hasn't changed for the actual instance | |
| 17:58:22 | dansmith | well, no | |
| 17:58:31 | dansmith | flavors stay with the instance, flavours are not a thing in nova :P | |
| 17:58:51 | artom | What do you mean not a thing? | |
| 17:59:02 | artom | Oh | |
| 17:59:18 | dansmith | artom: yeah, that's probably a good guideline, although some flavor extra_specs get overridden by image meta in some weird ways I think | |
| 18:00:17 | artom | Ugh. | |
| 18:00:27 | mriedem | NUMATopologyFilter gets values from flavors first, and if not set, checks the image meta | |
| 18:00:34 | artom | Just set everything to policy and wait for the bug reports then >:( | |
| 18:00:35 | mriedem | so flavor extra specs take precedence there | |
| 18:00:52 | dansmith | artom: that's the way it is now, and the bug we're fixing :P | |
| 18:00:54 | mriedem | oh wait nvm that | |
| 18:01:49 | mriedem | re the question about the az filter | |
| 18:01:50 | mriedem | https://review.openstack.org/#/c/446446/ | |
| 18:02:24 | mriedem | user can see when looking at AZs" | |
| 18:02:24 | mriedem | availability_zone key for a specific aggregate and accordingly change what the | |
| 18:02:24 | mriedem | can modify any metadata, it is possible to change the value of the | |
| 18:02:24 | mriedem | "Unfortunately, as an operator | |
| 18:05:35 | openstackgerrit | Merged openstack/nova master: vgpu: add enabled white list https://review.openstack.org/512580 | |
| 18:10:07 | mriedem | we persist the flavor with the request spec yes? | |
| 18:10:41 | dansmith | flavor id you mean? | |
| 18:10:46 | mriedem | the full flavor | |
| 18:11:01 | mriedem | looks like yes | |
| 18:11:03 | dansmith | hrm, I guess we do | |
| 18:11:14 | mriedem | which means, re the TrustedFilter question, | |
| 18:11:46 | mriedem | if the admin changes the flavor extra specs for the trusted filter after you've created an instance, when you rebuild or migrate that instance, the filter is going to work on the original flavor used to create the instance | |
| 18:11:48 | mriedem | not the modified one | |
| 18:12:02 | mriedem | *i think* | |
| 18:12:46 | artom | That's what I understood when dansmith said that flavoUrs stay with the instance, yeah | |
| 18:17:16 | mriedem | my favorite burstlet flavour is tripe | |
| 18:17:55 | mriedem | artom: dansmith: ok, some replies inline https://review.openstack.org/#/c/521186/ | |
| 18:18:48 | mriedem | dansmith: btw, i changed _GroupAntiAffinityFilter to False, ran functional tests and nothing failed | |
| 18:19:12 | dansmith | mriedem: it'll be non-deterministic | |
| 18:19:20 | mriedem | gha | |
| 18:19:22 | mriedem | *gah | |
| 18:19:25 | dansmith | because if it selects the other host by chance it'll be happy | |
| 18:19:49 | dansmith | it was oddly repeatable for me.. two tests validating the same thing (for two microversions) one would always pass the other would always fail | |
| 18:19:53 | dansmith | took me a while to figure out why | |
| 18:20:13 | dansmith | I was able to shake it up with different levels of concurrency and running the tests in isolation | |
| 18:20:30 | mriedem | test_rebuild_with_soft_anti_affinity ? | |
| 18:20:48 | mriedem | or test_rebuild_with_anti_affinity | |
| 18:20:58 | dansmith | soft I think | |
| 18:21:25 | mriedem | that one involves a weigher so yeah might be that one | |
| 18:21:27 | dansmith | I can try to repro if it's important | |
| 18:21:28 | mriedem | will run it a few times | |
| 18:21:58 | openstackgerrit | Eric Fried proposed openstack/nova master: Use ksa adapter for cinder client https://review.openstack.org/508345 | |
| 18:22:13 | mriedem | i am dangerously close to needing some deterministic lunch | |
| 18:23:01 | dansmith | mriedem: http://logs.openstack.org/86/521186/3/check/openstack-tox-functional/dc8ab81/testr_results.html.gz | |
| 18:23:03 | dansmith | that was the failure I tried to repro locally that led me down the path I think | |
| 18:48:20 | dansmith | artom_: mriedem well, now I can't get it to fail | |
| 18:49:24 | dansmith | oh, wait | |
| 18:49:24 | mriedem | :/ | |
| 18:49:36 | mriedem | was that with same_host or something? | |
| 18:49:37 | dansmith | I bet it's because I hit this before I was doing the force_hosts | |
| 18:49:58 | mriedem | ah | |
| 18:50:18 | dansmith | it was when I was going to do the check in conductor manager I think | |
| 18:50:29 | mriedem | so we can probably change that one then | |
| 18:50:33 | mriedem | which would help with the confusion | |
| 18:50:42 | dansmith | yeah I guess so | |
| 18:51:33 | mriedem | dansmith: artom: in general, what are your thoughts/feelings/hopes/dreams about just calling the hint _is_rebuild and the filter attribute RUN_FOR_REBUILD? then each filter decision is about that scope/use case rather than what policy means | |
| 18:52:16 | dansmith | I dunno, it feels too specific, but I can't come up with another reason to do this really | |
| 18:52:33 | mriedem | right, like you said, we could change it later if we have a need to generify it | |
| 18:53:01 | dansmith | yeah | |
| 18:53:08 | mriedem | we could also maybe remove the variable at some point later with rpc version changes, like passing an actual is_rebuild parameter to select_destinations or something | |
| 18:53:20 | dansmith | yeah | |
| 18:53:32 | mriedem | i'm not sure that would buy us much, except maybe more straight-forward | |
| 18:53:44 | dansmith | ideally it'd be operation="rebuild" to give us some room for the future | |
| 18:53:45 | dansmith | but yeah | |
| 18:53:51 | mriedem | sure | |
| 18:54:06 | mriedem | operation="mind crime" | |
| 18:54:12 | dansmith | heh | |
| 18:54:17 | mriedem | 80s queensryche reference for artom | |
| 18:58:18 | artom | I was -5 for half the 80s, though I do enjoy some of their music now :) | |
| 18:58:41 | artom | Renaming it to RUN_FOR_REBUILD would definitely make the scope clearer | |
| 18:58:46 | artom | I agree it's not pretty | |
| 18:59:25 | artom | Though I'm not as repulsed by the api <-> scheduler coupling - the scheduler knowing about rebuilds isn't as far fetched as it sounds | |
| 18:59:49 | artom | I think ideally I'd like more methods in the filters, like I said in my last comment | |
| 19:00:28 | artom | So host_passes for "can this host run this instance now?", host_acceptable for "can this host accept this instance, resource considerations aside", and maybe other ones for cases we haven't thought of | |
| 19:00:36 | artom | But that doesn't look very backportable | |
| 19:04:29 | openstackgerrit | Merged openstack/nova master: cleanup mapping/reqspec after archive instance https://review.openstack.org/515034 | |
| 19:05:29 | mriedem | mgagne: a couple of small changes to make here and then i think we're good https://review.openstack.org/#/c/503088 | |
| 19:06:26 | mriedem | artom: the scheduler is definitely aware of moves for placement allocations, even if it's not super obvious | |
| 19:06:35 | mgagne | mriedem: will work on it today. I think committed the Ironic release note by mistake, will reword as suggested | |
| 19:07:03 | mriedem | mgagne: yeah heh, that was my comment :) | |
| 19:07:14 | mgagne | didn't read yet :P, will do | |
| 19:07:59 | artom | mriedem, yeah, it decides which instances go to which hosts, to operations on instances that have to do with hosts aren't outside its domain :) | |
| 19:08:05 | artom | *so operations | |
| 19:08:28 | artom | If we started telling it about keypair updates I'd be more concerned ;) | |
| 19:08:37 | mriedem | artom: i mean this specifically https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L1035 | |
| 19:16:14 | efried | cdent Still around? | |
| 19:16:23 | cdent | yessir | |
| 19:16:33 | mgagne | mriedem: so should I refactor _generate_configdrive or not? | |
| 19:16:38 | efried | cdent Is there a way in gabbi for me to say "This must *not* be in the response" ? | |
| 19:17:30 | cdent | in a body or header? | |
| 19:17:38 | efried | body | |
| 19:18:12 | efried | I know about checking the length of a chunk of the response; will fall back on that if nothing else is available. | |
| 19:18:39 | cdent | there are a couple of additional options: | |
| 19:19:22 | cdent | if the surrounding chunk of json is small and you know all of it, you can make the value of the jsonpath be the entire chunk, instead of just a scalar value | |
| 19:19:37 | cdent | or you might be able to do something with regular expressions | |
| 19:19:49 | cdent | (the value side of the jsonpath statement can be a regex) | |