Posted	Nick	Remark
#openstack-nova - 2022-09-01
16:21:04	sean-k-mooney	ya, stop, update whatever you liek, explictly tell it to update config drive if you care, start
16:21:11	bauzas	because we're discussing a design change
16:21:40	bauzas	dansmith: yeah, something we would say "damn nova, please do the necessary to plumb my things"
16:21:42	sean-k-mooney	bauzas: i think we all realise that we likely wont make progress now
16:22:07	bauzas	an instance action would be nice to me, because it would get a status
16:22:21	bauzas	and the async thing would be simple for the user
16:22:35	bauzas	like, I started again and my userdata didn't updated, why ?
16:22:46	bauzas	=> server action tells me it failed
16:23:08	sean-k-mooney	well the server action can be blocking or async
16:23:25	sean-k-mooney	but it has a feeback mecahnim either way
16:23:26	gibi	this could be a very long running blocking call
16:23:28	bauzas	yup, the whole point is that it gives a clue why the userdata wasn't uptodate
16:23:45	sean-k-mooney	right it woudl be in the instance event log
16:23:59	bauzas	and until the userdata says "I'm updated", don't expect to get the new things if you start
16:24:01	gibi	we can also make the start to fail if it needed to regen but failed to
16:24:02	sean-k-mooney	if its async or in the respocne if blocking
16:24:22	sean-k-mooney	gibi: that woudl requrie trackign the dirty state
16:24:34	sean-k-mooney	and also some peopel might not care
16:25:16	gibi	I don't see how somebody explicitly updated the user_data and then don't case if that update is ending up in the VM being sarted
16:25:19	gibi	started
16:25:48	gibi	I think the dirty flag was bad because of shadow rpc
16:25:58	sean-k-mooney	im thinking about something else
16:26:14	sean-k-mooney	as a user i might not know if the user data is in config drive or not
16:26:26	sean-k-mooney	but i said start
16:26:38	sean-k-mooney	and i might not want tha to break in this case
16:27:19	gibi	I see
16:27:26	sean-k-mooney	the dirty flag was to give you the behaior that it would only boot if it succeed to update
16:27:42	bauzas	honestly, if I'm an user, I don't care about the internals
16:27:44	sean-k-mooney	if it failed at least in my version teh vm would have gone to error
16:27:57	bauzas	what I want to know is when my update succeeds and when I can use it
16:28:02	dansmith	sorry, I'm getting pulled away,
16:28:06	dansmith	but if it was an instance action,
16:28:18	dansmith	then the rebuild either works or doesn't, I can see what happened,
16:28:29	dansmith	and then I either get the old version on fail, or the new version on succeed
16:28:46	dansmith	if we just set a dirty flag and then fail to regen on start, then we've killed the instance with no way to restart
16:28:48	dansmith	which sucks
16:28:48	bauzas	yup, I get feedback from an user perspective
16:28:56	bauzas	yup, agreed
16:29:13	sean-k-mooney	jhartkopf: so based on the above
16:29:15	dansmith	we probably need some task_state or something to keep the user from starting it until the regen completes though
16:29:22	sean-k-mooney	jhartkopf: and the fact we are all runing out of steam
16:29:28	bauzas	mikal would say "spec'y spec'y"
16:29:31	dansmith	or just use instance lock on the compute node to hold off on any other requests.. I guess that's enough
16:29:32	sean-k-mooney	i think we need to disucss this again next cycle
16:29:53	bauzas	the next PTG will be virtual
16:30:05	bauzas	anyone can join, budged saved
16:30:24	sean-k-mooney	ya but we can reopne the sepc and discuss it again before htat
16:30:31	bauzas	oh yeah
16:30:58	sean-k-mooney	i see to ways we coudl go with the instance action by the way
16:31:05	sean-k-mooney	one is one for regeneratin cofnig drive
16:31:11	sean-k-mooney	the other is more targed for this feature
16:31:21	sean-k-mooney	an instance action to update user_data
16:31:30	sean-k-mooney	that either succeed or does not
16:31:49	sean-k-mooney	and have that be the only wya to update it
16:31:57	sean-k-mooney	so no updating it via server put
16:32:25	dansmith	yeah, the user should not see "regenerate config drive"
16:32:41	dansmith	so it should be "update my user_data" at the external surface for sure
16:32:52	sean-k-mooney	right
16:32:55	sean-k-mooney	so if we do that
16:33:16	sean-k-mooney	that dedicated instance action can "do the right thing" regardess of how the instance is booted
16:33:31	dansmith	right
16:33:42	sean-k-mooney	and returna 409 conflict if its not supprot by the driver or whatever
16:33:55	jhartkopf	sean-k-mooney: Oh that'd be bad news. Was hoping to get at least the stuff without config drives merged this cycle.
16:34:12	sean-k-mooney	but it can be atomic
16:34:40	JayF	o/, I have a handful of ironic driver patches I'm still trying to get backported thru. They are all clean backports and passing tests.
16:34:42	JayF	https://review.opendev.org/c/openstack/nova/+/854257 (no live migration tests on ironic driver changes -> yoga) https://review.opendev.org/c/openstack/nova/+/821351 (ignore plug_viles on ironic driver -> ussuri) https://review.opendev.org/c/openstack/nova/+/853546 (minimize window for a resource provider to be lost -> train)
16:34:42	bauzas	sean-k-mooney: dansmith: yeah, the user-surfaced API is the userdata, not the configdrive
16:35:01	bauzas	so the instance action has to be related to it
16:35:39	sean-k-mooney	JayF: did we land the skip of the migration job yet
16:35:47	JayF	sean-k-mooney: that's the yoga backport above
16:35:52	JayF	sean-k-mooney: the version -> master is in
16:35:55	sean-k-mooney	an cool
16:36:03	sean-k-mooney	i was onder if the master on had landed
16:36:05	bauzas	jhartkopf: the problem is that we can't introduce this userdata update by splitting without configdrive as we just agreed on a brand new API
16:36:24	JayF	oh, I've already checked all these -- previous branches have merged, these should be good to go. e.g. I'd approve these if they were ironic stable changes
16:36:32	bauzas	for consistency reasons, we have to hide the configdrive details from the user request
16:36:43	sean-k-mooney	bauzas: that and my +2 on the spec was contingent on it not depending on if you use configdrive or not
16:36:46	JayF	and elod helped me clean up the only piece around nova stable policy that's more strict than Ironic :D
16:37:33	bauzas	sean-k-mooney: that kind of design problems happening late in the cycle are common
16:38:14	bauzas	jhartkopf: this isn't at all about your implementation, this is rather about the fact we discovered some design problems we weren't considering at the spec review time
16:38:16	gibi	we should be better at doing this kind of design discussion before the FF day
16:38:37	gibi	but I don't know how
16:38:43	bauzas	honestly, this is the only blueprint that fails this for this cycle AFAICT
16:38:51	bauzas	gibi: we had precedents
16:39:07	bauzas	some spec approved and a design question raising late
16:39:08	jhartkopf	bauzas: I understand that, but it's really unfortunate though
16:39:52	bauzas	jhartkopf: I don't disagree with you and I understand how much this can be frustrating
16:40:01	artom	bauzas, wait, so ephemral disk, PCI, and manial will all make it?
16:40:12	artom	*Manilla
16:40:20	gibi	bauzas: I don't think we can detect all the design issues at spec time. But still I think we should be better than doing it at the day of FF
16:40:21	sean-k-mooney	not sure about manilla
16:40:22	bauzas	jhartkopf: I just hope you can understand that our API resources are important to us and we really care about the UX
16:40:39	sean-k-mooney	ephmeral also likely not
16:40:51	bauzas	artom: no, I was mentioning a design issue being raised
16:40:53	artom	Ah
16:41:38	bauzas	ephemerals and PCI are on their way but they're big and need a lot of back and forths
16:41:48	gibi	the only easy answer for me know is that I should have asked dansmith earlier to review the series
16:41:53	bauzas	but they hadn't required a redesign
16:42:11	bauzas	gibi: well, if you read the spec, I had concerns about the restart
16:42:37	dansmith	gibi: this is why I'm against yearly releases.. because this stuff, very unfortunately, only comes to a head when there's a deadline...

Earlier   Later