| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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 | |
| 14:16:11 | sean-k-mooney | no api microverion bumps in backports remember | |
| 14:16:33 | bauzas | sean-k-mooney: indeed, but it's the same with the existing | |
| 14:16:47 | sean-k-mooney | we allow flavor extra specs to change in backports | |
| 14:16:55 | sean-k-mooney | as they are not consierd a api change downstream | |
| 14:17:06 | sean-k-mooney | flavor extra specs are considerd unversioned | |
| 14:17:15 | johnthetubaguy | well, the spec was approved to make them part of the API | |
| 14:17:18 | bauzas | I mean, if we were discussing about backporting a feature adding a new API modification (even for a filter key), I would have said "sorry but no" | |
| 14:17:29 | sean-k-mooney | johnthetubaguy: i dont recall tat being in the spec | |
| 14:18:26 | johnthetubaguy | these implications where not gone through, that is true | |
| 14:19:25 | sean-k-mooney | johnthetubaguy: its not stated in the spec and i would have objected to that change without makeing flavor extraspecs ovo | |
| 14:19:27 | sean-k-mooney | https://github.com/openstack/nova-specs/blob/master/specs/ussuri/approved/flavor-extra-spec-validators.rst | |
| 14:20:04 | johnthetubaguy | sean-k-mooney: ovo would have been a good approach, that is why I suggested custom namespacing instead of the flag | |
| 14:20:07 | sean-k-mooney | specicilly if we want to make extraspecs versioned then i wouls have propsed seperating this into two fileds | |
| 14:20:18 | bauzas | or rather https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/flavor-extra-spec-validators.html ;) | |
| 14:20:24 | sean-k-mooney | one that is an ovo and the other that is a bag for random stings | |
| 14:21:00 | johnthetubaguy | not sure why we need two apis, but it would work | |
| 14:21:11 | sean-k-mooney | johnthetubaguy: backwards compat | |
| 14:21:26 | johnthetubaguy | I mean instead of key namespace like traits | |
| 14:21:45 | johnthetubaguy | anyways, it seems a bit late to reopen all that | |
| 14:21:50 | sean-k-mooney | well we could but it might be hard to detangel | |
| 14:22:14 | sean-k-mooney | perhaps a bit :) | |
| 14:22:33 | sean-k-mooney | so the current approch is predicated on extra_sepcs not beign microverion bumps | |
| 14:22:40 | sean-k-mooney | that is the assumtion that spec is making | |
| 14:23:20 | sean-k-mooney | if we want to be stricter we could but i kind of feel like we shoudl do that as a followup in ussuri | |
| 14:23:29 | sean-k-mooney | *victoria | |
| 14:23:31 | johnthetubaguy | sean-k-mooney: is that stated in the spec though, I think it is just the assumption some people made, and others made the opposite | |
| 14:24:17 | johnthetubaguy | ... but if we add anything in the API we have to support it *for ever* | |