| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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 | johnthetubaguy | sean-k-mooney: we will after this change | |
| 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: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 | |
| 14:34:11 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Report COMPUTE_RESCUE_BFV and check during rescue https://review.opendev.org/701429 | |
| 14:34:11 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Add support for stable device rescue https://review.opendev.org/700812 | |
| 14:34:12 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212 | |
| 14:34:12 | openstackgerrit | Lee Yarwood proposed openstack/nova master: api: Introduce microverion 2.86 allowing boot from volume rescue https://review.opendev.org/701430 | |
| 14:34:13 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Support boot from volume stable device instance rescue https://review.opendev.org/701431 | |
| 14:34:15 | johnthetubaguy | hmm, I guess I worry *what* validation is actually being done, i.e. what is the supported list of that given Nova endpoint | |
| 14:34:43 | dansmith | johnthetubaguy: meaning you say validation=true and you don't know if the endpoint is new enough to validate numa_nodes or something? | |
| 14:35:30 | dansmith | because if so, the easy way is to make validation=(yes|no|strict), and if you ask for strict validation while passing a key it doesn't support, then it fails and tells you | |
| 14:35:30 | bauzas | johnthetubaguy: dansmith: stephenfin: sean-k-mooney: gibi: honestly, can we just enable the feature by being permissive now (and not having a microversion now) and discuss about those concerns in a later change ? | |
| 14:36:02 | dansmith | bauzas: not sure how we would do that | |
| 14:36:03 | stephenfin | bauzas: It's not permissive at the moment though, it's a no-op | |
| 14:36:24 | johnthetubaguy | its strict by default in the new microversion right? | |
| 14:36:29 | stephenfin | yes | |
| 14:36:35 | bauzas | dansmith: I personnally feel we only need a microversion once we default to be strict | |
| 14:36:53 | dansmith | bauzas: we need a microversion as soon as we add a parameter, AFAIK | |
| 14:36:54 | bauzas | my counter-proposal is to enable this feature but be opt-in | |
| 14:37:14 | johnthetubaguy | dansmith: hmm, I guess, although I thought we were against that approach before. I am more worried about the user listing the extra specs and trying to understand them | |
| 14:37:36 | bauzas | dansmith: yeah, if you mean a extraspec key, I don't disagree | |
| 14:37:49 | dansmith | johnthetubaguy: to be honest, the importance of this feature is pretty low to me | |
| 14:37:57 | johnthetubaguy | the strict/permissive/disabled thing sure needs a microversion to be added | |