| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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 | johnthetubaguy | while its not what your code currently does... its actually an API definition / docs change. | |
| 14:55:49 | dansmith | johnthetubaguy: what does permissive mean? just log errors? | |
| 14:55:57 | sean-k-mooney | dansmith: yep | |
| 14:56:02 | stephenfin | nope | |
| 14:56:04 | johnthetubaguy | dansmith: it means only validate known keys, | |
| 14:56:05 | dansmith | sean-k-mooney: I was expecting we'd namespace everything, so things would become system:hw:thing | |
| 14:56:20 | stephenfin | permissive means 'hw:numa_nodes=asdassdf' is rejected, but 'sdfsdfsd:sdfsdf' isn't | |
| 14:56:21 | sean-k-mooney | stephenfin: it logs unknone keys | |
| 14:56:31 | sean-k-mooney | or did you not do that in the end | |
| 14:56:33 | stephenfin | and rejects them with a 4xx error | |
| 14:56:40 | stephenfin | oh,sorry | |
| 14:56:43 | johnthetubaguy | I didn't see a log in the code, thankfully | |
| 14:56:43 | dansmith | that's not permissive | |
| 14:56:45 | stephenfin | logs the unknown keys, yes | |
| 14:56:49 | stephenfin | or does it | |
| 14:57:01 | stephenfin | I'm not sure if I bothered included a log | |
| 14:57:04 | stephenfin | *including | |
| 14:57:10 | bauzas | you didn't | |
| 14:57:15 | stephenfin | ETOOMUCHNOISE | |
| 14:57:19 | sean-k-mooney | dansmith: strict rejects unkown keys with an error | |
| 14:57:34 | sean-k-mooney | permisive allows them and validates the values of keys it know about | |
| 14:57:40 | bauzas | honestly, that's why I want to move on | |
| 14:57:42 | sean-k-mooney | and disabled is a noop | |
| 14:57:42 | dansmith | sean-k-mooney: unknown keys in namespaces like hw: I assume? | |
| 14:57:51 | bauzas | we need to enable something and then discuss on a separate change | |
| 14:57:58 | stephenfin | any unknown keys | |
| 14:58:07 | stephenfin | e.g. hw:cpu_policyyy | |
| 14:58:13 | stephenfin | which is why I wanted strict | |
| 14:58:30 | dansmith | but people can use their own custom keys for scheduler behavior yeah? so we can't reject *everything* | |
| 14:58:35 | bauzas | stephenfin: it can still be a recommended choice | |
| 14:58:37 | johnthetubaguy | yeah, I think if we are strict for all known namespaces, it would be much better | |
| 14:58:43 | bauzas | stephenfin: but this would only be a doc thing | |
| 14:59:00 | bauzas | johnthetubaguy: we had this discussion 3 years ago | |
| 14:59:19 | johnthetubaguy | bauzas: we probably did, I might have been wrong then too | |
| 14:59:20 | stephenfin | dansmith: yes, and I've documented how they can add their own validators for whatever extra specs they want | |
| 14:59:27 | bauzas | johnthetubaguy: and we said we had to be accepting *any* key because we can't assume whether it's a typo or a custom key | |
| 14:59:28 | dansmith | wait, | |
| 14:59:32 | stephenfin | assuming they don't want to simply opt of validation | |
| 14:59:35 | sean-k-mooney | dansmith: right hence the idea of having "custom:" namespace where you can add stuff we woudl never validate | |
| 14:59:38 | dansmith | so in strict mode they have to write code in order to be able to use things like the json filter? | |
| 15:00:04 | bauzas | the 'custom:' namespace is good but this requires some proper signaling (and at least one cycle of deprecation) | |
| 15:00:15 | sean-k-mooney | dansmith: json filter uses shcduler hint | |
| 15:00:28 | bauzas | ie. we say "okay, look, custom filters will continue to work without any change in U and V" | |
| 15:00:41 | dansmith | there's some filter we can hit custom fields on the flavor isn't there? | |
| 15:00:53 | bauzas | "but starting from W, you will need to change your flavors to use a custom: prefix" | |
| 15:01:09 | sean-k-mooney | dansmith: yes compute capablity filter and the aggartioninstnaceType filter | |
| 15:01:14 | stephenfin | yes, 'CapabilitiesFilter' and 'AggregateInstanceExtraSpecsFilter' filters | |
| 15:01:17 | sean-k-mooney | dansmith: both are supproted | |
| 15:01:22 | stephenfin | and I've enumerated the known values for both | |
| 15:01:23 | sean-k-mooney | it jsut allows any key | |
| 15:01:31 | sean-k-mooney | if you use there namespaces | |
| 15:01:34 | stephenfin | *known keys | |
| 15:01:50 | stephenfin | the values are basically wildcards because of how flexible thoseare | |
| 15:01:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: workarounds: Add option to disable native LUKSv1 decryption by QEMU https://review.opendev.org/708030 | |
| 15:01:52 | openstackgerrit | Lee Yarwood proposed openstack/nova master: workarounds: Add option to locally attach RBD volumes https://review.opendev.org/708029 | |
| 15:01:53 | stephenfin | *those are | |
| 15:01:58 | melwitt | frickler: yes https://docs.openstack.org/releasenotes/nova/stein.html#known-issues | |
| 15:02:13 | sean-k-mooney | stephenfin: you allow any key in there namespace right | |
| 15:02:42 | sean-k-mooney | because those filters allow arbitray key names as long as they are in the same namespaces | |
| 15:02:49 | bauzas | sean-k-mooney: dansmith: stephenfin: honestly, I think I'm +2 on a deprecation policy for those filters | |
| 15:03:07 | bauzas | like, no longer supporting those wildcards at W | |
| 15:03:16 | bauzas | and the same goes for custom filters | |
| 15:03:20 | sean-k-mooney | bauzas: that a sperate topic | |
| 15:03:27 | bauzas | sean-k-mooney: no, that's tied | |
| 15:03:27 | stephenfin | sean-k-mooney: not the Capabilities filter anyway - those have to map to a field on the HostState object or ComputeNode o.v.o | |
| 15:03:38 | frickler | melwitt: ha, thx for pointing me to the obvious docs | |
| 15:03:42 | bauzas | we can't be strict on enforcing keys until we fixed those messed keys | |
| 15:03:44 | sean-k-mooney | stephenfin: ya i was thinking of the other one | |
| 15:03:55 | bauzas | (internal team meeting FTW) | |
| 15:04:07 | sean-k-mooney | bauzas: we can they have there own namespace | |
| 15:04:07 | dansmith | okay I see the a.i.e.s filter already has a namespace, I didn't realize | |
| 15:04:08 | stephenfin | sean-k-mooney: yes, that's wildcarded | |
| 15:04:17 | sean-k-mooney | but ya i guess i should join intrenal call | |
| 15:04:21 | stephenfin | yup, since Grizzly (thanks, Intel) | |
| 15:04:40 | bauzas | that bears me (joke) | |
| 15:05:34 | sean-k-mooney | dansmith: yep i made sure those fileter would still work in the spec review | |
| 15:05:51 | sean-k-mooney | sicne they used to be used for dpdk/numa stuff alot | |
| 15:05:56 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM - Test stable device rescue tests with BFV instances https://review.opendev.org/710050 | |
| 15:06:48 | bauzas | honestly, that's now 4 hours we're discussing over this and I'm out of steam now | |
| 15:07:21 | dansmith | bauzas: wait until people start asking about how to do this in osc in a year :) | |
| 15:07:24 | bauzas | so, again, either we make this permissive now or we just punt this for now | |
| 15:08:01 | bauzas | ... | |