| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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 | 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: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: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 | johnthetubaguy | in a new microversion, the API can basically do what we want (ish), i.e. requires client changes to uses it | |
| 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: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 | sean-k-mooney | spatel: yep so you need to follow osa insturction to upgrade | |
| 13:56:07 | stephenfin | The idea being that no one can override our definitions of extra specs | |
| 13:56:17 | spatel | is the a way to fix by hand ? | |
| 13:56:38 | sean-k-mooney | you can fix it by hand but no i would not expect that to be the correct way | |
| 13:57:03 | stephenfin | as a reminder, "strict" = key and value validation, "permissive" = value validation only, "disabled" = no validation | |
| 13:57:04 | sean-k-mooney | spatel: you should proably just do a minor update to the latest version fo stable stine | |
| 13:57:08 | spatel | sean-k-mooney: i want to try by hand first and then will do upgrade to make sure it works | |
| 13:57:27 | spatel | is this compute side fix or neutron server? | |
| 13:57:35 | spatel | sorry controller i meant | |
| 13:57:36 | stephenfin | so with this, one could configure e.g. 'myfancyextraspec=foo', but never 'hw:cpu_policy=garbage' | |
| 13:57:46 | sean-k-mooney | stephenfin: i dont think we should drop disabled | |
| 13:58:00 | stephenfin | how come? | |
| 13:58:21 | sean-k-mooney | for the resaons i suggested it was required in the first place | |
| 13:58:52 | sean-k-mooney | i want to ensure if we modify the flavor create command in the futre we can still disable validation andu use whatever was intoduced in the new microverion | |
| 13:59:12 | johnthetubaguy | sean-k-mooney: I am not understanding those yet, could you give a concrete example please? | |
| 14:00:09 | bauzas | stephenfin: on a call | |
| 14:00:15 | sean-k-mooney | if we modfiy flavor create to allow setting the flavor accesss as part of a singel atoimc command in 2.xy | |
| 14:00:32 | sean-k-mooney | but still want to disable validation we cant do both without disabled | |
| 14:00:58 | johnthetubaguy | sean-k-mooney: sorry, I don't understand why | |
| 14:01:26 | sean-k-mooney | im assuming 2.xy is after the micoverion that intoduces validation | |
| 14:01:37 | sean-k-mooney | and since its on by default that woudl be an issue right | |
| 14:01:39 | johnthetubaguy | in some future microversion, we can change what is allowed, to whatever we need it to be | |
| 14:02:03 | sean-k-mooney | permissive still spams the logs with the warning | |
| 14:02:18 | sean-k-mooney | and not everyone wants that | |
| 14:03:01 | johnthetubaguy | so like we shouldn't spam the logs, but I don't understand the API request you are trying to describe and why its a problem? | |
| 14:03:52 | sean-k-mooney | its only a problm if i have a vendor exteion | |
| 14:03:58 | openstackgerrit | jayaditya gupta proposed openstack/nova master: Support for --overwrite flag for nova-manage placement heal_allocations command Closes-Bug:#1868997 https://review.opendev.org/715395 | |
| 14:04:03 | sean-k-mooney | or out of tree driver | |
| 14:04:12 | johnthetubaguy | sean-k-mooney: but that is what permissive is there for | |
| 14:04:17 | stephenfin | those are permitted by permissive | |
| 14:04:23 | sean-k-mooney | permissve still does value valdiation | |
| 14:04:41 | sean-k-mooney | and there is nothing stopping out of tree driver or vendor extions form extenting the allowed values | |
| 14:04:48 | johnthetubaguy | correct, your out of tree thing is BAD if it changes an existing extra_spec, and needs fixing | |
| 14:05:16 | sean-k-mooney | proably but it proably been bad for years | |
| 14:05:21 | johnthetubaguy | agreed | |
| 14:05:51 | sean-k-mooney | i dont really understand why having a way to turn off validation is an issue | |
| 14:06:02 | sean-k-mooney | we have to have that code path for older microverions anyway | |