| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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* | |
| 14:24:28 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/flavor-extra-spec-validators.html#rest-api-impact | |
| 14:24:34 | sean-k-mooney | that is all that is stated | |
| 14:24:36 | johnthetubaguy | so I would rather we land the most restrictive thing, and make it more open in the future | |
| 14:25:10 | sean-k-mooney | if we do that it will never happen | |
| 14:25:44 | johnthetubaguy | not if people don't need the extra things, which is great, we get a better smaller API | |
| 14:26:16 | sean-k-mooney | i would like dansmith to weigh in on this before we make any discision | |
| 14:26:23 | johnthetubaguy | me too | |
| 14:27:00 | sean-k-mooney | i understand where you are comming form and i was supportive of this because i wanted the api to be stricter | |
| 14:27:18 | dansmith | should I just read the scrollback? | |
| 14:28:07 | sean-k-mooney | dansmith: we were talking about the flavor extra specs validatiors, specifcally the query arg to contol validation | |
| 14:28:35 | sean-k-mooney | it would appear that some assumed after this spec all extra_spec changes would involve a micro version bump | |
| 14:29:16 | sean-k-mooney | which raise the question why have the policy. i made the opisite assumtion that we would continue to not bump the microver when altering extra_specs | |
| 14:29:55 | dansmith | is the question not the microversion for the validation param, but whether or not we bump the microversion for future validators? | |
| 14:30:34 | sean-k-mooney | there are two questions. do we bump the mircoverion for evey extra_spec change going forward | |
| 14:31:06 | sean-k-mooney | and what are the implciation of the validation parm in either case | |
| 14:31:48 | dansmith | so, I thought the plan was to make validation optional through the flag, isn't that right? | |
| 14:31:53 | bauzas | dansmith: see the open discussion in https://review.opendev.org/#/c/708436/16//COMMIT_MSG@12 | |
| 14:32:08 | sean-k-mooney | dansmith: yes that was the plan in the spec | |
| 14:32:27 | dansmith | because if so, I would expect that we don't treat the extra_specs *themselves* as versioned and schema-controlled, which means no microversion for each new one, | |
| 14:32:31 | bauzas | dansmith: the main concern we were discussing is whether there was an interop issue | |
| 14:32:40 | dansmith | and rather the only thing we're versioning is the *behavior* of optionally validating them | |
| 14:34:10 | openstackgerrit | Lee Yarwood proposed openstack/nova master: virt: Provide block_device_info during rescue https://review.opendev.org/700811 | |