| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-29 | |||
| 15:29:45 | sean-k-mooney | the reason we would wont that is if we add this in 2.68 and in 2.69 we add another field to the flavor but we still want to disable validtion it would be nice to be able to turn it off | |
| 15:30:18 | bauzas | honestly, leave them time to change their flavors | |
| 15:30:21 | stephenfin | sean-k-mooney: yeah, I've been suggesting using the older microversion purely as a stop gap to allow us iron out the kinks | |
| 15:30:31 | dansmith | IMHO, and AFAICT, validation is *just* to help make the admin's life easier so they don't have to keep booting instances to test that they completely broke an extra_spec right? | |
| 15:30:42 | bauzas | also, are we proposing to fix existing embedded flavors ? | |
| 15:30:45 | sean-k-mooney | but that would not work if the thing i wanted to set was added in 2.69 | |
| 15:30:45 | dansmith | so being able to turn it off in an emergency doesn't seem like a bad thing to me | |
| 15:30:54 | stephenfin | This also won't break existing flavors. It'll only prevent them creating new broken flavors | |
| 15:30:55 | dansmith | you're not going to periodically fsck your flavors so, what does it matter? | |
| 15:30:58 | bauzas | stephenfin: I mean, instance's embedded flavors | |
| 15:31:30 | sean-k-mooney | stephenfin: creating or updating | |
| 15:31:40 | stephenfin | bauzas: Nope. Out of scope for this. This focuses purely on setting new flavor extra specs | |
| 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 | introduces a whole slew of ordering issues | |
| 15:34:42 | stephenfin | otherwise you'd have to set e.g. 'hw:cpu_policy' before 'hw:cpu_dedicated_policy' | |
| 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:43 | efried | but not things like "this extra spec is only relevant to the libvirt driver" | |
| 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 | - strict: above, plus fail on unrecognized keys. | |
| 15:47:58 | efried | - permissive: only validate values, only for keys we recognize. Ignore unrecognized keys. | |
| 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 | I'm not married to the names, but I thought three modes: | |
| 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 | |