| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 11:53:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: doc: require openstack client change for every new API microversion https://review.opendev.org/717727 | |
| 11:53:41 | kplant | that's still not a show stopper | |
| 11:53:41 | sean-k-mooney | unit tests are awsome :) | |
| 11:53:48 | sean-k-mooney | although docs would also help | |
| 11:54:01 | kplant | as long as the _set string is _only_ negations, every other vcpu should implicitly be available for scheduling, no? | |
| 11:54:52 | sean-k-mooney | that is the behavior i would want as an enduser | |
| 11:56:26 | sean-k-mooney | but no unfortunetly that is not what the behvior is today | |
| 11:56:30 | kplant | i probably just over thought it and gave myself a reason to be lazy and use reserved_host_cpus instead of cpu_dedicated_set | |
| 11:56:41 | kplant | oh, really? | |
| 11:57:00 | openstackgerrit | Merged openstack/nova master: Add info about affinity requests to the troubleshooting doc https://review.opendev.org/715092 | |
| 11:57:01 | sean-k-mooney | it starts with an empty set cpuset_ids = set() | |
| 11:57:08 | openstackgerrit | Merged openstack/nova master: Stabilize functional tests https://review.opendev.org/717070 | |
| 11:57:09 | kplant | eek | |
| 11:57:15 | openstackgerrit | Merged openstack/nova master: Introduce scope_types in security groups policy https://review.opendev.org/716786 | |
| 11:57:16 | sean-k-mooney | and after we loop over every thing cpuset_ids -= cpuset_reject_ids | |
| 11:57:39 | sean-k-mooney | it would not be hard to add that behavior. | |
| 11:58:02 | kplant | i would expect assuming all cpus to actually be faster code | |
| 11:58:13 | kplant | that's more likely in line with what the result will be | |
| 11:58:37 | sean-k-mooney | kplant: that code does not know how many cpus you have | |
| 11:59:44 | kplant | fair, it would come from sql | |
| 12:00:45 | sean-k-mooney | not quite where this is used is on the comptue node before we store the info in the db but anyway if you do have a propoasl for improving this feel free to write it up | |
| 12:02:09 | kplant | is this the better behavior? the current behavior forces the user to be explicit | |
| 12:02:39 | kplant | i guess i can always submit it and get input that way | |
| 12:06:40 | sean-k-mooney | kplant: if you dont set the config options all cores are assumed to be usable | |
| 12:06:59 | sean-k-mooney | kplant: so the idea was of you opt in you should say what you want | |
| 12:08:35 | kplant | i think that mindset still applies, just change the behavior from cpu_*_set to a merge behavior instead of replace | |
| 12:08:43 | kplant | i think that's reasonable | |
| 12:08:47 | sean-k-mooney | kplant: that said i have wanted to remove the reserved_host_cpus options since we first added vcpu_pin_set so makeing it nicer to use the reserved_host_cpus will help with that goal | |
| 12:08:49 | kplant | just want to make sure before i waste time with a bp | |
| 12:10:26 | kplant | waste other people's time* | |
| 12:10:33 | sean-k-mooney | kplant: well we would need to keep backwards compatbliy so we could not make it merge by defaul but we could change the behavior so that if you only specify negation then we woud assume all cpus were valid and apply the negation | |
| 12:11:23 | kplant | very fair point | |
| 12:11:37 | kplant | that would make cpu_dedicated_set = "4" == all cpus | |
| 12:12:26 | sean-k-mooney | kplant: ill file a bug | |
| 12:12:58 | kplant | appreciate that | |
| 12:16:05 | sean-k-mooney | kplant: the only issue really is that now that we have two ranges cpu_share_set and cpu_dedicated_set | |
| 12:16:18 | sean-k-mooney | it become less uesful but its still useful | |
| 12:17:13 | kplant | i guess the winner between the two would be the more explicit option? | |
| 12:17:21 | kplant | share_set: "1-5" | |
| 12:17:25 | kplant | dedicate_set: "3" | |
| 12:17:34 | sean-k-mooney | no you get an error if you do that | |
| 12:17:50 | sean-k-mooney | and i dont think we want that much magic in the config option parsing | |
| 12:18:33 | kplant | that works | |
| 12:19:14 | kplant | so i guess here's a difficult question | |
| 12:19:27 | kplant | if you do mix shared and dedicated on the same host, and leave N cpus unspecified | |
| 12:19:34 | kplant | are they shared? are they dedicated? | |
| 12:19:49 | kplant | with the current implementation they're neither | |
| 12:21:57 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1871096 | |
| 12:21:58 | openstack | Launchpad bug 1871096 in OpenStack Compute (nova) "when only a negation is specified for cpu_*_sets we should assume all cpus are vaild and subtract the negated cpus" [Wishlist,Triaged] | |
| 12:22:51 | sean-k-mooney | kplant: if you dont set the config options all cpus will be reported as VCPU resouce class which is used for shared cpus | |
| 12:23:18 | sean-k-mooney | and then we have fallback logic in the scheulder currently to allow pinned guest to land there | |
| 12:23:53 | sean-k-mooney | if you use cpu pinning however we woudl stonly prefer if you used cpu_dedicated_set | |
| 12:24:35 | sean-k-mooney | eventually we might remove the fallback and required it | |
| 12:25:11 | johnthetubaguy | stephenfin: did you update the api-ref for those extra params? | |
| 12:31:51 | kplant | sean-k-mooney: thanks! | |
| 12:43:07 | stephenfin | johnthetubaguy: Oh, probably not. Will respin now | |
| 12:43:48 | johnthetubaguy | stephenfin: I am struggling with this validation mode stuff... should have been a discussion on the spec I know, but didn't see this one go by | |
| 12:44:25 | johnthetubaguy | not going to block it or anything, just can't see how it works for users | |
| 12:47:44 | stephenfin | The discussion for that was mostly done on IRC, unfortunately :( Earlier versions of the spec didn't have the concept. It was all or nothing | |
| 12:47:48 | johnthetubaguy | stephenfin: that "disabled" mode I think is what worries me, I think the "permissive" isn't so bad, although I would prefer some namespacing of keys, as its easier to understand | |
| 12:48:34 | stephenfin | wdym namespacing of keys? | |
| 12:48:46 | johnthetubaguy | well placement traits is the example | |
| 12:48:54 | johnthetubaguy | if as a user you list the traits | |
| 12:49:07 | johnthetubaguy | you can see which ones are standard, and which ones your deployer has probably made up | |
| 12:49:25 | johnthetubaguy | i.e. can you go read the openstack docs to find out what it is, or otherwise | |
| 12:50:14 | johnthetubaguy | ... I had a lot of pushback in Rackspace on not allowing vendor extensions, which is what extra specs is right. Namespacing the crazy seems the least we could do for our users | |
| 12:51:10 | stephenfin | So insist on a namespace for any custom extra specs? | |
| 12:51:33 | johnthetubaguy | think of the user listing extra specs on the flavors | |
| 12:51:43 | johnthetubaguy | they want to workout what they mean, where do they look | |
| 12:52:01 | johnthetubaguy | you could just see its missing in openstack docs, but that doesn't mean too much | |
| 12:52:08 | johnthetubaguy | then you grep the source code... nothing | |
| 12:52:38 | johnthetubaguy | then you ask the group running your cloud, and they forgot, the person who added the flavor left last week | |
| 12:53:10 | johnthetubaguy | ... I got carried away there, but really its that problem I am thinking of fixing | |
| 12:53:51 | johnthetubaguy | say we used a namesapce, anything invalid keys could get translated to CUSTOM_<old_name> in the new API microversion | |
| 12:54:33 | johnthetubaguy | there could well be a better fix | |
| 12:55:56 | stephenfin | ah, see I'd been more focused on catching typos or extra specs that don't do anything (like 'hw:mem_policy', which a lot of TripleO roles were setting for years, despite it never being implemented) | |
| 12:56:09 | johnthetubaguy | ... an API that lists all supported extra_spec keys in a given release, isn't a bad way forward, I would allow adding new keys without a microversion | |
| 12:57:23 | johnthetubaguy | yeah, agreed the typos are important to fix, and you have done that (with or without the disabled and permissive flags) | |
| 12:57:23 | stephenfin | so for this, I was under the impression that things were pretty freeform and outside of the extra specs we control (in-tree ones), they had to stay that way | |
| 12:57:53 | johnthetubaguy | I don't think we want that, its just we never got around to fixing it | |
| 12:58:21 | johnthetubaguy | similar conversions around scheduler hints | |
| 12:58:36 | johnthetubaguy | although, that might be just what is in my head | |
| 13:01:27 | sean-k-mooney | johnthetubaguy: the reason disabled exists is so we can in the future have a new micoroverions that modify flavor creattion without forceing validation | |
| 13:02:28 | sean-k-mooney | johnthetubaguy: flavor specs can be seen by users and we allow third party filters so i dont think traslating them to custom: is valid | |
| 13:02:35 | johnthetubaguy | sean-k-mooney: my worry is it means someone has decided to change how some existing key works, which sounds dangerous to me | |
| 13:02:49 | sean-k-mooney | johnthetubaguy: that is not what htis is for | |
| 13:02:51 | johnthetubaguy | sean-k-mooney: it would only be in a new microversion, for all unsupported keys | |
| 13:03:18 | sean-k-mooney | johnthetubaguy: its so that if you are using non standard flavor extra specs for filters or out of try drivers you can trun off the validation | |
| 13:03:18 | johnthetubaguy | in a new microversion, the API can basically do what we want (ish), i.e. requires client changes to uses it | |
| 13:03:50 | sean-k-mooney | johnthetubaguy: the flavor creation api can but the rest of openstack has to work the same | |
| 13:03:59 | sean-k-mooney | so the filters wont be mircoverion dependant | |
| 13:05:05 | sean-k-mooney | johnthetubaguy: i would not expect the translation to happen by default | |
| 13:05:14 | sean-k-mooney | which is what would happen with nova client | |
| 13:05:33 | sean-k-mooney | which is guess is another reason to prefer osc | |
| 13:07:02 | sean-k-mooney | johnthetubaguy: as i said before i think a good way forward would be to deprecated non namespaces extra specs | |
| 13:07:15 | sean-k-mooney | create a custom: namespcae for those that need it | |
| 13:07:27 | sean-k-mooney | and reserve all other namespaces for nova to use | |
| 13:09:08 | sean-k-mooney | we have already broken the behvairo or extra specs but we have so far never removed them but i would ok tighening the contract around extra specs and how they can be modifed | |
| 13:10:20 | sean-k-mooney | i aggree however with the current approch in the flavor validation work. | |
| 13:12:17 | sean-k-mooney | also extra_specs are not for vender extentions. they are missues for that but they are for feature requests | |