| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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 | |
| 14:08:54 | sean-k-mooney | some people will just not want to pay the cost of validation | |
| 14:10:00 | johnthetubaguy | sean-k-mooney: they can use the older microversion, till sometime after the the sun becomes a red giant and we up the minimum supported microversion | |
| 14:10:30 | sean-k-mooney | johnthetubaguy: they cant if they want to use a feature in a later microverion at the same time | |
| 14:10:48 | sean-k-mooney | johnthetubaguy: this is modifying flaovr update and create | |
| 14:11:12 | sean-k-mooney | if we modify either after we add valdiation we either always get validation or you have to do two api calls | |
| 14:11:25 | sean-k-mooney | that was my orginal argment for disabled | |
| 14:11:45 | johnthetubaguy | to be clear, this is our policy on these matters: https://docs.openstack.org/nova/latest/contributor/policies.html#out-of-tree-support | |
| 14:12:15 | sean-k-mooney | johnthetubaguy: to be clear my orginal argument was nothing to do with "out of tree support" :) | |
| 14:12:20 | johnthetubaguy | now I think allowing out of tree keys in extra specs has been allowed for so long, we have to support it somehow, which technically violates the policy | |
| 14:12:47 | johnthetubaguy | the question I have is how best to do that | |
| 14:13:00 | sean-k-mooney | johnthetubaguy: we dont require microverion bumps for extra specs | |
| 14:13:17 | johnthetubaguy | the disabled flag basically allows interop problems in the API | |
| 14:13:21 | sean-k-mooney | so there is also no way to determin if an extra spec is supproted form the api | |
| 14:13:21 | johnthetubaguy | sean-k-mooney: we will after this change | |
| 14:13:30 | sean-k-mooney | johnthetubaguy: that was not part of the proposal | |
| 14:13:48 | bauzas | stephenfin: ^ | |
| 14:13:49 | bauzas | ? | |
| 14:13:55 | johnthetubaguy | I was just trying to do that really | |
| 14:14:04 | johnthetubaguy | not very well mind :/ | |
| 14:14:15 | johnthetubaguy | I think we shouldn't have the disabled flag | |
| 14:14:35 | johnthetubaguy | ... actually I don't like the permissive flag, but I agree we need to support the use case it allows | |
| 14:14:50 | sean-k-mooney | johnthetubaguy: where did you think we were agreeign to do a microverion bump on extra spec changes? | |
| 14:15:07 | sean-k-mooney | becasue that was not discussed as part of the spec or planned | |
| 14:15:13 | johnthetubaguy | sean-k-mooney: because any time we change API validation, its a microversion bump | |
| 14:15:29 | sean-k-mooney | not with what was propsoed | |
| 14:15:40 | bauzas | sean-k-mooney: I think we all agree on this | |
| 14:15:47 | johnthetubaguy | I am more stating the current API rules, which we haven't proposed a change to | |
| 14:15:49 | bauzas | (about providing a microversion for a new extraspec key) | |
| 14:16:00 | sean-k-mooney | bauzas: if we do then we can never do feature backports downstream | |
| 14:16:04 | bauzas | but we can discuss on a spec modification if you want | |