Posted	Nick	Remark
#openstack-nova - 2020-01-29
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
15:51:13	efried	we can call it 'warn'
15:51:22	stephenfin	efried: vs. just retrying one by one?
15:51:26	efried	yes
15:51:44	efried	or "I want to test drive this feature"
15:51:45	sean-k-mooney	i suggested permissive to mirror selinux but warn would be fine
15:51:54	efried	"but still create my flavor"
15:51:56	sean-k-mooney	although that implice that strict should be error
15:52:01	efried	really for completeness
15:52:31	stephenfin	Okay. You're aware the warnings are only going to be in the logs though, yeah?
15:52:37	stephenfin	So I'm not sure how much feedback you're going to be getting
15:52:53	efried	It would be nice to find a way to send them back to the CLI, but yeah, I get it.
15:53:04	stephenfin	compared to just trying one by one 'til you find the erroneous extra spec
15:53:06	sean-k-mooney	well for errors we can put it in the resonce body
15:53:20	stephenfin	sean-k-mooney: right, but not for warnings
15:53:21	efried	I think that ^ would be nice for a future microversion, don't need to do it now.
15:53:22	sean-k-mooney	for wraning maybe we could alter the respocne to include them too
15:53:37	stephenfin	for those we already have a body - the updated flavor (I think)
15:53:53	sean-k-mooney	ya it should be the full flavor object
15:54:05	sean-k-mooney	but we could extend it from the mircoverion on
15:54:06	stephenfin	yup, so no way to get back that warning via the API
15:54:11	sean-k-mooney	that said its a nice to have
15:54:36	efried	so then yeah, call it 'off' and the warnings are in the logs
15:54:43	sean-k-mooney	sure there is we just change the api respoce to also have validtion warning but lets leave that out of scope for now
15:54:53	stephenfin	efried: ack
15:55:22	efried	(note that we technically wouldn't need 'strict', since that's the default, but again for completeness it would be nice to support it)

Earlier   Later