| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-21 | |||
| 17:52:18 | mriedem | i think in one of the periodic tasks | |
| 17:52:34 | efried | mriedem Yeah, I couldn't remember if that was niraj_singh, but I don't think so. | |
| 17:52:59 | mriedem | efried: https://review.openstack.org/#/c/384799/ | |
| 17:53:07 | efried | mriedem Oh, actually I was thinking of someone who was trying to use service auth from *within* cinder. | |
| 17:53:29 | artom | dansmith, mriedem, I think we need to get stephenfin to look at the PCI and NUMA bits when he comes back tomorrow | |
| 17:53:50 | dansmith | okay I'm off tomorrow and mriedem is too I think | |
| 17:53:55 | mriedem | pci is extra specs only | |
| 17:54:01 | mriedem | i asked stephen about that yesterday | |
| 17:54:05 | mriedem | numa is definitely a resource thing | |
| 17:54:11 | mriedem | we do claims on numa limits in the resource tracker | |
| 17:54:13 | artom | mriedem, can an admin change them though? | |
| 17:54:50 | mriedem | an admin could change the pci passthrough settings in flavor extra specs, sure | |
| 17:54:58 | artom | For NUMA the cpu and thread policy can change, I dunno if that can give rise to the situation where the host can no longer accept them | |
| 17:55:22 | mriedem | changing extra specs on an existing flavor would be kind of a bad move i think | |
| 17:55:31 | mriedem | but we allow it | |
| 17:55:33 | dansmith | the flavor embedded in the instance will have the pci stuff then, which means we won't see the changed extra_specs from the top-level flavor in the rebuild | |
| 17:56:12 | dansmith | the cpu and thread policy change in the image meta might be a reason to do the rebuild though, | |
| 17:56:18 | dansmith | so I dunno what to say about that | |
| 17:57:54 | artom | dansmith, oh right, that's true, flavours stay with instances now | |
| 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 | "Unfortunately, as an operator | |
| 18:02:24 | mriedem | can modify any metadata, it is possible to change the value of the | |
| 18:02:24 | mriedem | availability_zone key for a specific aggregate and accordingly change what the | |
| 18:02:24 | mriedem | user can see when looking at AZs" | |
| 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 | mriedem | :/ | |
| 18:49:24 | dansmith | oh, wait | |
| 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 | |