| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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 | |
| 13:50:22 | sean-k-mooney | https://github.com/openstack/releases/commit/f23ff65cbf52ea1c5f7b2985cab56ce23a5264b7 | |
| 13:51:11 | spatel | sean-k-mooney: how do i verify os-vif version? | |
| 13:51:22 | sean-k-mooney | how did you install openstack | |
| 13:51:29 | spatel | openstack-ansible | |
| 13:51:38 | sean-k-mooney | package install or source install | |
| 13:51:47 | spatel | sources | |
| 13:52:09 | spatel | /openstack/venvs/neutron-19.0.0.0rc3.dev6 | |
| 13:52:10 | sean-k-mooney | the source install uses pip in a viruatl env so you would enter the venv for nova and do "pip freeze" | |
| 13:53:53 | sean-k-mooney | so "source /openstack/nova.../bin activate" followed by "pip freeze | grep vif" then "deactivate" | |
| 13:54:13 | spatel | nova or neutron? | |
| 13:54:14 | sean-k-mooney | so "source /openstack/nova.../bin/activate" followed by "pip freeze | grep vif" then "deactivate" | |
| 13:54:18 | spatel | let me try | |
| 13:54:19 | sean-k-mooney | nova | |
| 13:54:46 | sean-k-mooney | well both should have the same version but neutorn only started using os-vif in stine or train | |
| 13:54:55 | sean-k-mooney | nova has used it for much longer | |
| 13:55:38 | spatel | sean-k-mooney: i am running os-vif==1.15.1 | |
| 13:55:45 | stephenfin | bauzas, gibi: Are you okay with me dropping the 'disabled' policy from https://review.opendev.org/#/c/708436/16/nova/api/openstack/compute/schemas/flavors_extraspecs.py@39 ? | |
| 13:56:02 | spatel | look like buggy version | |
| 13:56:07 | stephenfin | The idea being that no one can override our definitions of extra specs | |
| 13:56:07 | sean-k-mooney | spatel: yep so you need to follow osa insturction to upgrade | |
| 13:56:17 | spatel | is the a way to fix by hand ? | |