| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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 | |
| 14:44:18 | johnthetubaguy | sean-k-mooney: that was because we asked them to, so our API is an abstraction that is useful, rather than a bag of virt driver flags | |
| 14:44:18 | bauzas | option B : microversion everything | |
| 14:44:20 | dansmith | johnthetubaguy: yeah, doesn't seem like we can do that now without a large migration of everyone's custom specs, or our system ones | |
| 14:44:43 | sean-k-mooney | johnthetubaguy: yep and i would like if we could add back abstrations | |
| 14:44:53 | sean-k-mooney | johnthetubaguy: i noted as much in early verion of the validation patch | |
| 14:45:04 | sean-k-mooney | johnthetubaguy: its why we have we should move x and other comment in the code | |
| 14:45:46 | johnthetubaguy | dansmith: yeah, I would sadly agree that doing that is likely a waste of our valuable time at this point, FWIW, I find the documentation and structure useful on its own, it helped with image props. | |
| 14:45:47 | sean-k-mooney | ya the migration of the instance embeded flavor would be a pain although we could do it if neded | |
| 14:46:21 | dansmith | johnthetubaguy: agree, it's not worth it at this point | |
| 14:46:23 | sean-k-mooney | johnthetubaguy: well part of stephens work is to imporve the docs | |
| 14:46:34 | johnthetubaguy | so my proposal earlier was to alias in the new microversion, so you add a prefix for all non-system ones, but its a pain | |
| 14:46:54 | dansmith | so, crazy idea | |
| 14:47:45 | dansmith | what if we add a new namespace prefix that itself implies that the spec is validated.. something like system:numa_nodes, which would require validation, but otherwise be the same as numa_nodes, at least for the foreseeable future? | |
| 14:48:20 | sean-k-mooney | dansmith: i would prefer to define custom: | |
| 14:48:21 | dansmith | that would give us something we could eventually warn people about, deprecate the non-system numa_nodes in the future and then eventually land on anything not in system: becomes the "wild west of custom stuff" | |
| 14:48:23 | sean-k-mooney | to opt out | |
| 14:48:26 | sean-k-mooney | rather then opt in | |
| 14:48:40 | bauzas | sorry, need to drop, urgent kitchen issue | |
| 14:48:40 | sean-k-mooney | and just validate all other namespaced extra specs | |
| 14:48:45 | dansmith | sean-k-mooney: well, the problem is right now the entire non-namespaced space is custom | |
| 14:48:46 | bauzas | (kids at home, lovely) | |
| 14:49:00 | sean-k-mooney | dansmith: actully not quite | |
| 14:49:06 | sean-k-mooney | we messed up one key | |
| 14:49:09 | sean-k-mooney | but more or less | |
| 14:49:27 | dansmith | sean-k-mooney: like bauzas says, I think that throwing the switch to opt-out right now is not great | |
| 14:49:27 | frickler | I'm seeing nova-api lockup when running under apache2 mod-wsgi-py3 on stein with >1 thread enabled, is this a known issue? traceback looks like this and the server stops responding after answering some few requests correctly http://paste.openstack.org/show/PhzU6ZXQnkfrDjyAAAoe/ | |
| 14:49:59 | sean-k-mooney | ya whcih is why the valdiation parma was added | |
| 14:50:04 | sean-k-mooney | or old micorverions | |
| 14:50:10 | dansmith | right, | |
| 14:50:26 | dansmith | but as johnthetubaguy has said, it's hard for people to know what is being checked or not | |
| 14:50:47 | sean-k-mooney | yes that is true | |
| 14:51:03 | johnthetubaguy | a list of validated namespaces is a nice way forward | |
| 14:51:04 | sean-k-mooney | we also will have different behavior between osc and nova client | |
| 14:51:18 | johnthetubaguy | ideally the ones we already use would all fit into that list | |
| 14:51:27 | sean-k-mooney | johnthetubaguy: currently that would be everyting nova knows about in tree | |
| 14:51:29 | stephenfin | I can do permissive for now, then add an API to list all recognized extra specs in a future version with a new microversion. At that point, we could also switch to strict | |
| 14:51:43 | stephenfin | Would that do the trick? | |
| 14:51:47 | johnthetubaguy | the others are just not validated... we land at permissive for everything | |
| 14:51:53 | dansmith | sean-k-mooney: actually, it'd be everything we know how to validate | |
| 14:52:11 | johnthetubaguy | stephenfin: what dansmith is suggesting is a bit nicer, and the reverse of my CUSTOM namespace proposal | |
| 14:52:18 | sean-k-mooney | dansmith: stephenfin added validation for everyting i think | |
| 14:52:35 | sean-k-mooney | dansmith: but yes you are technically correct | |
| 14:52:50 | johnthetubaguy | basically be strict for all the in tree namesapces we use today, permissive for everything else | |
| 14:52:51 | stephenfin | johnthetubaguy: right, but who's going to do that work? | |
| 14:53:10 | sean-k-mooney | i had envisioned that after this if you adde an extra specs you would add a validator or extend the existing ones | |
| 14:53:28 | dansmith | sean-k-mooney: it would be easier to enforce that in code with a namespace | |
| 14:54:21 | sean-k-mooney | yes i just dont want operator to have to updated there exiting instance | |
| 14:54:37 | dansmith | well, they won't for the time being | |
| 14:55:00 | dansmith | we still honor the non-namespaced version, unvalidated for the foreseeable future | |
| 14:55:02 | stephenfin | johnthetubaguy: ah, wait, you mean be strict for e.g. 'hw:' namespaced extra specs, but not 'foo:' ? | |
| 14:55:07 | johnthetubaguy | so possible way forward, maybe... we drop the strict and disabled mode, we merge with permissive as the default, but we redefine the API as what dansmith said (i.e. only a microversion to add a new supported namesapce) | |
| 14:55:10 | sean-k-mooney | the other downside to a new name spaces if if we only have one the we have to put everyhtin into it | |
| 14:55:11 | johnthetubaguy | stephenfin: yeah | |
| 14:55:49 | dansmith | johnthetubaguy: what does permissive mean? just log errors? | |
| 14:55:49 | johnthetubaguy | while its not what your code currently does... its actually an API definition / docs change. | |