| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-29 | |||
| 15:31:47 | sean-k-mooney | you want to be able to do the valiation optionaly on flaovr updates too | |
| 15:32:03 | dansmith | sean-k-mooney: that's true, if you're updating a flavor that currently doesn't pass validation | |
| 15:32:12 | stephenfin | We could look into doing that with a nova-manage command (or nova-audit) command in the future but I'm not even thinking about that at the moment | |
| 15:32:38 | stephenfin | sean-k-mooney: Well, setting or updating a new extra spec | |
| 15:32:42 | sean-k-mooney | bauzas: ya for not if you need to update embeded flavor resize | |
| 15:32:52 | sean-k-mooney | stephenfin: yes | |
| 15:33:03 | dansmith | er, wait, stephenfin are you just doing validation on the one spec you're setting during that operation or on the whole flavor as it would be with the spec set? | |
| 15:33:19 | stephenfin | dansmith: Just the one spec | |
| 15:33:23 | dansmith | ah okay | |
| 15:33:27 | bauzas | I need to reread the spec because I'm unclear of some bits | |
| 15:33:38 | stephenfin | I don't plan to e.g. audit the existing extra specs on a flavor when setting a new one | |
| 15:33:46 | stephenfin | gibi: o/ | |
| 15:33:49 | sean-k-mooney | dansmith: the spec says that while there is a depency between some spec we wont enforce that | |
| 15:33:50 | dansmith | stephenfin: aren't there some specs that depend on each other, like being able to set something that isn't valid unless some other spec says you have that thing? | |
| 15:33:55 | dansmith | okay gotcha | |
| 15:33:59 | bauzas | OK, flavor set, there is | |
| 15:34:02 | gibi | o/ | |
| 15:34:06 | sean-k-mooney | we could add that in the future | |
| 15:34:08 | stephenfin | dansmith: There are but we can't enforce it at the API level | |
| 15:34:21 | dansmith | stephenfin: because some have co-dependency? | |
| 15:34:32 | efried | we would be able to enforce some interdependencies | |
| 15:34:42 | stephenfin | otherwise you'd have to set e.g. 'hw:cpu_policy' before 'hw:cpu_dedicated_policy' | |
| 15:34:42 | stephenfin | introduces a whole slew of ordering issues | |
| 15:34:43 | efried | but not things like "this extra spec is only relevant to the libvirt driver" | |
| 15:34:43 | sean-k-mooney | stephenfin: in some case we can but often the depency can be fulfiled by the image too | |
| 15:34:56 | dansmith | stephenfin: right, I dunno that that's bad necessarily | |
| 15:35:10 | dansmith | stephenfin: you just couldn't enforce that "X and Y have to be both present or both absent" I think | |
| 15:35:44 | dansmith | anyway, my concern over the update was if you were tweaking a flavor that currently doesn't pass and you can't get yourself out of trouble with single ops | |
| 15:35:51 | dansmith | sounds like that's not a thing | |
| 15:36:27 | sean-k-mooney | ya it should not be an issue in what is proposed for this cycle | |
| 15:36:35 | stephenfin | I could do that enforcement but I probably don't need to do it in the API | |
| 15:36:55 | dansmith | well, I'm not sure what the point is if not in the API :) | |
| 15:37:15 | sean-k-mooney | as i said in some cases the co depency can be fulfiled by the image so we often dont know if it will be fuliled until the boot request | |
| 15:37:24 | sean-k-mooney | so that a diffent level of validation | |
| 15:37:31 | dansmith | sean-k-mooney: ah, that is a very good point | |
| 15:37:43 | stephenfin | oh, good point | |
| 15:37:44 | sean-k-mooney | if it a co depency that is purly fulfiled in the flavor | |
| 15:37:52 | dansmith | yup | |
| 15:37:57 | sean-k-mooney | maybe but that feels like a ux bug | |
| 15:38:11 | efried | that ship has sailed though | |
| 15:38:16 | sean-k-mooney | yes | |
| 15:38:48 | stephenfin | anyway, I think having the registry to validate extra spec names and the separate validators to handle the values gets us an awful lot over what we have at the moment | |
| 15:39:35 | sean-k-mooney | stephenfin: but yes i agree with that statemnet | |
| 15:39:41 | stephenfin | and it's the lowest hanging fruit, which is nice :) | |
| 15:40:36 | stephenfin | I'm going to update the spec to drop the YAML idea in favour of entrypoints and also add the escape hatch qparam | |
| 15:40:55 | stephenfin | dansmith, efried, sean-k-mooney, bauzas: That make sense to you folks? | |
| 15:41:08 | sean-k-mooney | ya im fine with that | |
| 15:41:11 | dansmith | yup | |
| 15:41:34 | dansmith | I didn't catch earlier discussion, but was gibi opposed to all that? | |
| 15:41:37 | bauzas | cool | |
| 15:41:45 | efried | grudgingly accept entrypoints over yaml. qparam ++ | |
| 15:41:58 | sean-k-mooney | incidentally if you felt like writhing a blog on it or example plugin you could provide a yaml one | |
| 15:42:06 | stephenfin | he wanted the qparam too, I think, but also suggested we use YAML for everything if we were using it | |
| 15:42:25 | stephenfin | so we didn't have two different representations of the same thing | |
| 15:42:41 | efried | so now we have one representation | |
| 15:42:45 | efried | it's python. | |
| 15:42:57 | sean-k-mooney | yes | |
| 15:42:59 | stephenfin | if everything's an object, that concern's resolved. gibi will let me know if he doesn't agree, I'm sure | |
| 15:43:06 | stephenfin | efried: Don't you love it | |
| 15:43:30 | sean-k-mooney | we can even assume its python 3 at long last | |
| 15:43:32 | dansmith | cool | |
| 15:43:34 | efried | If we're providing the qparam so I can push through my snowflake without writing python code for it, I'm okay. | |
| 15:43:46 | stephenfin | \o/ sweet | |
| 15:44:14 | efried | I still think it would be a good idea to have a 'permissive' mode on that qparam | |
| 15:44:43 | stephenfin | efried: what's the difference vs. enable/disable? | |
| 15:44:59 | efried | If I'm constructing my flavor all at once, rather than one extra spec at a time, it gives me the advantage of validating the known/in-tree things while ignoring the snowflakes. | |
| 15:45:09 | sean-k-mooney | permissive mode i guess would log a warning or let you know it failed validation | |
| 15:45:18 | stephenfin | oh, that's what I was going to do for off | |
| 15:45:19 | efried | using two separate calls is a workaround to that | |
| 15:45:30 | efried | yeah, 'off' is 'warn'. | |
| 15:45:41 | efried | but that's for values too | |
| 15:45:46 | sean-k-mooney | oh i was thing off ment you know off as in dont even check | |
| 15:45:47 | stephenfin | no, I was thinking off means you'll never be able to disable validation for the in-tree stuff | |
| 15:45:52 | stephenfin | sean-k-mooney: nope | |
| 15:45:53 | efried | 'permissive' means don't restrict to known keys. | |
| 15:46:05 | stephenfin | wait, that sentence doesn't make sense | |
| 15:46:31 | stephenfin | no, I was thinking off means don't worry about unrecognised keys but do validate values for the known ones | |
| 15:46:35 | stephenfin | so you'll never be able to disable validation for the in-tree stuff | |
| 15:46:45 | stephenfin | better. | |
| 15:47:11 | sean-k-mooney | in my head 'stirct' = know keys only, 'permissive' mean allow unkonw keys but warn, off mean dont do validation at all | |
| 15:47:47 | stephenfin | would you ever want to turn it off for *everything*? | |
| 15:47:58 | efried | I'm not married to the names, but I thought three modes: | |
| 15:47:58 | efried | - off: we don't 4xx for anything. We can still run the validators, but just warn if we find something awry. | |
| 15:47:58 | efried | - permissive: only validate values, only for keys we recognize. Ignore unrecognized keys. | |
| 15:47:58 | efried | - strict: above, plus fail on unrecognized keys. | |
| 15:48:01 | sean-k-mooney | its what you will get for the old microversion | |
| 15:48:13 | sean-k-mooney | so i thnk it makes sense to represent that code path as an option | |
| 15:48:36 | stephenfin | efried: That mostly makes sense but I'm wondering what off is useful for | |
| 15:49:07 | sean-k-mooney | stephenfin: off is basicaly whatever behavior you get with the old microverison | |
| 15:49:36 | stephenfin | right, but is that behaviour ever desirable though? | |
| 15:49:38 | sean-k-mooney | so if im using a newer micoverion for the flavor endpoint that add something not in the old one i can still turn off the vlidation | |
| 15:49:42 | efried | stephenfin: We forgot or messed up an in-tree one, and don't want to wait for the fix. Could flip to the prior microversion, but the warnings would give me a way to sort of manually make sure everything else is kosher. | |
| 15:49:46 | sean-k-mooney | stephenfin: yes | |
| 15:50:13 | sean-k-mooney | stephenfin: there was a spec for composable flavor recently | |
| 15:50:16 | stephenfin | efried: wdym by "everything else" | |
| 15:50:28 | efried | the remainder of the extra specs in my request. | |
| 15:50:34 | sean-k-mooney | if that was approved and landed after this feature we might want to use that without validation | |
| 15:50:57 | stephenfin | oh, yes, you can set multiple extra specs at once. duh | |
| 15:50:57 | efried | I try with strict/permissive, I get a bounce on extra spec X, I redrive with 'off' and make sure the only warning I get is on X. | |
| 15:51:04 | sean-k-mooney | efried: im more or less ok with your deffintions by the way your off just does a littel more then i expected | |