| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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: libvirt: Add support for stable device rescue https://review.opendev.org/700812 | |
| 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: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:12 | openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212 | |
| 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 | 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: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: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 | |
| 14:38:13 | dansmith | we have no param right now, so we need a microversion regardless right? | |
| 14:38:22 | johnthetubaguy | dansmith: +1 | |
| 14:38:23 | dansmith | and why as the yes/no/strict thing rejected before? | |
| 14:38:28 | dansmith | *was | |
| 14:38:40 | bauzas | okay, nevermind my counter-proposal, you're right | |
| 14:38:46 | bauzas | a microversion has to be added anyways | |
| 14:38:49 | stephenfin | it's not been rejected: that's what we have at the moment | |
| 14:38:53 | johnthetubaguy | it might have been silently ignored actually... | |
| 14:39:07 | bauzas | but I just feel we need to be permissive as default until we come up with a solid consensus on what we agree | |
| 14:39:18 | sean-k-mooney | johnthetubaguy: that would be an implemation detail of the route lib we are using if it was ignored | |
| 14:39:20 | stephenfin | johnthetubaguy: yeah, no query arg validation on that end point at the moment | |
| 14:39:23 | sean-k-mooney | its still an invalid query | |
| 14:39:26 | johnthetubaguy | (just because that API didn't have any query params before) | |
| 14:39:32 | bauzas | I tried to capture the problems and the proposals in https://review.opendev.org/#/c/708436/16//COMMIT_MSG | |
| 14:39:49 | dansmith | bauzas: I would prefer we default to non-strict validation if that's what you mean | |
| 14:39:57 | bauzas | correct | |
| 14:40:20 | bauzas | 2.86 would enable the feature | |
| 14:40:27 | bauzas | by being permissive | |
| 14:40:45 | johnthetubaguy | dansmith: OK, yeah, that would consistent with not needing a microversion for new extra specs, but lets admins opt into avoid a typo | |
| 14:41:14 | johnthetubaguy | honestly, my preference is to make these a real part of the API, and controlled in microversions, as I find the whole thing a mess to use right now | |
| 14:41:19 | sean-k-mooney | johnthetubaguy: extra specs are generaly backend speicic too so are not portabl in genreal | |
| 14:41:52 | dansmith | johnthetubaguy: but extra_specs are open-ended anyway, so it seems odd to me to have some set of them, not even namespaced, be hard-version-controlled | |
| 14:41:55 | bauzas | sean-k-mooney: and I hate this | |
| 14:41:57 | sean-k-mooney | e.g. they need knoladge of the way the cloud was configured (filters, virtdriver, versions) | |
| 14:42:15 | bauzas | sean-k-mooney: in particular the libvirt knobs we introduced | |
| 14:42:24 | dansmith | sean-k-mooney: that's why I don't really want this validation in the first place | |
| 14:42:26 | bauzas | those are utterly specifics | |
| 14:42:32 | sean-k-mooney | bauzas: sure but without normallising extra_spcs wich is a differnet topic we cant fix that | |
| 14:42:40 | bauzas | hence being permissive | |
| 14:42:47 | sean-k-mooney | bauzas: no the libvirt ones are no worse the the powervm or vmware ones | |
| 14:42:54 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in tenant tenant usage policies https://review.opendev.org/717587 | |
| 14:43:07 | sean-k-mooney | bauzas: many of the other virt diriver stated using the libvirt ones after we standarised them | |
| 14:43:29 | johnthetubaguy | dansmith: I guess I like what we did with traits, and wanted that for scheduler hints and extra specs, granted its hard to do retrospectively | |
| 14:43:34 | bauzas | (12:17:50) bauzas: ... or we set it to permissive by default | |
| 14:43:57 | bauzas | tbc, there are two alternatives | |
| 14:44:07 | bauzas | option A : let the operators opt-in | |
| 14:44:15 | sean-k-mooney | johnthetubaguy: schduler hints are seperate | |