Earlier  
Posted Nick Remark
#openstack-nova - 2020-04-06
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
14:06:22 sean-k-mooney so its just if disable do old code path
14:06:30 sean-k-mooney e.g. do nothing
14:06:35 johnthetubaguy because it encourages really bad, basically unsupported, behaviour
14:06:47 johnthetubaguy https://docs.openstack.org/nova/latest/contributor/policies.html#out-of-tree-support
14:06:57 sean-k-mooney not really
14:07:13 sean-k-mooney it would encurage it if it was the default
14:07:16 sean-k-mooney but its not
14:07:44 sean-k-mooney anyway i dont want to hold up the validation work as i want to see that land
14:07:59 johnthetubaguy To be clear, our dev policy says we should not support any of these out of tree things
14:08:03 sean-k-mooney so if it must be removed so be it but i dont think that is the correct chose
14:08:29 sean-k-mooney sure but this is not jsut for out of tree things
14:08:30 bauzas johnthetubaguy: stephenfin: I'm back

Earlier   Later