Posted	Nick	Remark
#openstack-nova - 2019-07-19
13:56:12	efried	cool, thanks.
13:56:16	openstackgerrit	**** proposed openstack/nova master: Nova: node should be deleted when last service is deleted https://review.opendev.org/671731
13:57:14	sean-k-mooney	am ^
13:57:30	sean-k-mooney	no ...?
13:57:49	dansmith	lol
13:58:06	sean-k-mooney	apperently there is a bluepirnt but the link does not work
13:58:12	gibi	efried: so we have more than one node under a compute service. the admin wants to configure some node specific thing via the yaml file. It works for a while but then the node is moved under another compute service where the yaml file has different config. How this allows the admin to specify config for a single ironic node properly?
13:59:35	efried	gibi: If they want to have a config for "one specific ironic node no matter which compute service it's under" they could deploy the same config (a single file, that identifies that ironic node explicitly) to all compute hosts.
13:59:57	dansmith	gibi: yep, if the admin has different files on different nodes, then a rebalance will change inventory, regardless of if they use $COMPUTE_NODE or not.. that'll need to be a ..node: warning probably regardless
14:00:17	sean-k-mooney	dansmith: oh its just a bad commit title
14:00:35	dansmith	sean-k-mooney: apparently the submitter is a secret agent
14:00:43	dansmith	who cannot reveal their identity
14:00:45	gibi	so the templating only helps if the config in the yaml file is not node specific but compute service specific
14:00:46	sean-k-mooney	apparently so
14:01:11	sean-k-mooney	too bad they didnt update there commit email or username
14:01:21	dansmith	gibi: specific to all the nodes managed by that compute, but you have a good point:
14:01:46	gibi	but _all_ node changes so it is not well defined
14:01:49	dansmith	gibi: some people with different ironic node types would want to have a different selector but still apply one definition to multiple things
14:01:54	efried	gibi: Yes. Or if you know you want all of your ironic nodes in your deployment to have some common characteristic, like a trait. You could effect that by deploying one section with $COMPUTE_NODE to each host instead of all N to each compute host.
14:02:35	dansmith	the identification section presumably offers us the ability to identify nodes by means other than $COMPUTE_NODE or uuid,
14:02:54	efried	dansmith: as of PS13 it allows you to identify by name
14:03:13	dansmith	so that we can say things like "any node managed by this service with inventory of CUSTOM_IRONIC_GOLD would be matched
14:03:13	efried	earlier revs had a whole panoply of identification mechanisms, but we trimmed it down to the bare bones.
14:03:14	dansmith	efried: name isn't super helpful in this case, but ... yeah
14:03:29	dansmith	and that's good for early revs I think
14:03:46	gibi	OK, I think I see the use case of the templating now.
14:03:47	efried	but yes, you make a good case for future expansion of the identification section.
14:03:54	dansmith	I'm saying that's a good reason for having identification be a section and not a key
14:03:55	dansmith	right
14:04:30	gibi	we might need a warning for ironic admins about using the yaml for node specific config
14:04:44	dansmith	like I said, a ..note: somewhere for sure
14:04:49	gibi	OK
14:05:01	gibi	let me read PS13 through, but I think I'm +2 on the spec
14:05:06	efried	Thanks gibi
14:10:35	artom	dansmith, dunno if you saw efried's adding of yourself to https://review.opendev.org/#/c/671471/, could I pester you some more for it?
14:11:02	gibi	efried: does changing 'ensure' to 'additional' keeps the intended behavior idepmotent? I mean if I restart a compute serivce it won't try to re-create the inventory if already exists
14:11:13	dansmith	artom: I did not
14:11:46	dansmith	gibi: it's still idempotent language to me
14:11:50	efried	gibi: yes, it's just a bikeshed of the word being used. I think I explained the rationale in the comment on PS12
14:12:14	efried	gibi: it's more than just "restart a compute service" -- this thing runs on every periodic
14:12:15	gibi	dansmith: I more after the behavior. if that is idepmontent then I'm happy
14:12:33	gibi	efried: OK. then I'm happy :)
14:12:37	dansmith	gibi: same behavior, more descriptive (IMHO) wording
14:12:43	efried	It makes me happy to make you happy, gibi
14:13:08	gibi	dansmith: OK. I accept the language change blindly as I'm not a native speakre
14:13:22	dansmith	heh
14:13:36	gibi	... and try to learn in the process
14:13:47	efried	don't try to learn too much from s/ensure/additional/
14:13:52	efried	that way lies madness
14:14:18	dansmith	efried: stop mocking me
14:14:20	efried	you can learn things about Dan, but not about English
14:14:23	efried	jinx
14:14:43	efried	kisses
14:14:44	gibi	:)
14:19:49	gibi	I'm +2 on the provider config spec
14:20:24	gibi	and I guess it is good time to inform you that I will disappeare for two weeks of vacation starting in an hour
14:22:52	efried	phew, then I'm glad I nabbed you for that +2. Have a great vacation gibi!
14:23:02	gibi	efried: thanks!
14:28:46	cdent	enjoy your time off gibi
14:28:59	gibi	cdent: thanks
14:31:51	dansmith	artom: you have to fix your many typos anyway, so I think you should move the code to a single check to LOG.warning on startup and then I'd be +2 if not for needing some diversity on it
14:32:16	artom	dansmith, in _init_host?
14:32:27	artom	Yeah, that'd make sense
14:32:27	dansmith	that'd be startup yeah :)
14:32:46	sean-k-mooney	if you put it in _init_host i would perfonally make it stop the agent booting
14:32:57	dansmith	no
14:33:04	artom	It wouldn't stop it
14:33:10	artom	But... it might take a long time
14:33:12	dansmith	this should be a LOG.warning
14:33:13	sean-k-mooney	im fine with it just being a warning to
14:33:21	artom	Not sure if that's acceptable
14:33:35	dansmith	artom: also a reno, just in case anyone is relying on this to do their homework for them
14:34:20	dansmith	artom: how long does this take? I'm not sure why it'd be slow really
14:34:29	artom	The bug's env has > 1000 nics, they timed it to over 2 minutes
14:34:40	artom	==========
14:34:41	artom	==========
14:34:41	artom	sys 2m27.918s
14:34:41	artom	user 0m4.358s
14:34:41	artom	real 2m32.642s
14:34:41	artom	$ time python -c "import nova.compute.utils; nova.compute.utils.get_machine_ips()"
14:34:59	efried	wow
14:35:14	dansmith	which thing takes long? listing the nics themselves?
14:35:20	dansmith	because that really shouldn't take that long
14:35:26	efried	yeah, is there not a quicker way to find out if my IP is on the system?
14:35:35	efried	ifconfig -a | grep ??
14:35:53	artom	efried, could be that "dumb", yeah. Would we be cool with this?
14:36:03	dansmith	if it's the list, then not much can be done, but if it's our processing, we could limit to 100 nics and bail after, or something
14:36:05	artom	ifconfig isn't on every system nowadays, but `ip` is
14:36:12	efried	considering what we're shooting for here, I would be totally fine with something that "dumb".
14:36:14	dansmith	no, don't do ip|grep
14:36:27	efried	if we were relying on this for real functionality that would be one thing
14:36:30	dansmith	this has been in place for four years and one person has complained,
14:36:34	efried	but this is a best-effort sanity check
14:36:40	dansmith	so I think once at startup which is way less impactful should be fine
14:36:47	artom	dansmith, well, thousands of nics aren't exactly common :)
14:36:53	dansmith	right
14:37:07	dansmith	which is why it's not a problem to do this for the 99.999% I think
14:37:15	efried	and as dansmith noted in the original, it's possible for it to fail and everything still be alright.
14:37:17	artom	I'm just worried there might be something that implicitly relies on compute service starting up in less than a few seconds
14:37:33	dansmith	artom: we have tons of things that are long-running in compute startup,

Earlier   Later