| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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 | |
| 13:13:03 | openstackgerrit | Merged openstack/nova master: Add test coverage of existing server external events policies https://review.opendev.org/717155 | |
| 13:13:11 | openstackgerrit | Merged openstack/nova master: Introduce scope_types in server external events https://review.opendev.org/717167 | |
| 13:41:50 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Add support for new cyborg extra specs https://review.opendev.org/716222 | |
| 13:44:52 | spatel | sean-k-mooney: morning! hope you guys are safe. | |
| 13:45:09 | spatel | I want to talk about - https://bugs.launchpad.net/os-vif/+bug/1837252 | |
| 13:45:10 | openstack | Launchpad bug 1837252 in os-vif stein "[OSSA-2019-004] Ageing time of 0 disables linuxbridge MAC learning (CVE-2019-15753)" [High,Fix committed] - Assigned to sean mooney (sean-k-mooney) | |
| 13:46:01 | spatel | I have two cloud running queens and stein and queens has ageing 300 but stein has 0 | |
| 13:46:14 | spatel | its kind of security issue at this point | |
| 13:46:33 | sean-k-mooney | spatel: that has already been fixed in stien | |
| 13:47:17 | spatel | hmm! why i am still seeing flooding on stein ? i check aging and its 0 ( disabled) | |
| 13:47:41 | sean-k-mooney | spatel: you are using linux bridge or ovs? | |
| 13:47:47 | spatel | Linuxbridge | |
| 13:48:08 | sean-k-mooney | then you dont have the correct version of os-vif | |
| 13:49:03 | sean-k-mooney | let me check if we have don a release | |
| 13:49:04 | spatel | hmm! how do i verify and lets say i don't have then any hand fix ? | |
| 13:49:08 | sean-k-mooney | https://github.com/openstack/os-vif/commit/ec9d5430300c908ea9a1c64151eee7af522a44e7 | |
| 13:49:20 | sean-k-mooney | we merged it onto the stable branch in july | |
| 13:50:20 | sean-k-mooney | spatel: it was fixed in 1.15.2 | |