Posted	Nick	Remark
#openstack-nova - 2019-11-20
14:53:34	dansmith	but the problem is that ironic nodes specified there may not exist as providers on startup, is that it?
14:53:53	efried	that's pretty much the only scenario that makes us have to deal with this, yeah.
14:54:23	dansmith	so we wanted to make that hard-fail if you provide something that doesn't exist there yeah?
14:54:28	efried	no
14:54:48	efried	generically the "problem" is that theoretically you can specify a config by $name and another by $uuid, but those are for the same node, but we wouldn't know that until that node "appeared".
14:55:04	efried	In practice this shouldn't be possible because for ironic, $name == $uuid.
14:56:03	dansmith	you mean if you had two entries in the list, one by name and one by uuid and they were in fact the same provider?
14:56:08	efried	right
14:56:44	dansmith	that seems like a really tiny detail to be concerned about.. did this come up in some testing or something?
14:56:53	efried	more code inspection
14:57:06	dansmith	remind me why we have the by-name option anyway?
14:57:10	efried	ikr
14:57:27	dansmith	uuid or the "self" option should really be all we need I would think
14:57:30	efried	It was because you don't necessarily know the UUID yet in a green field.
14:57:44	efried	but you want your tripleo to be able to lay down the config a priori.
14:57:46	dansmith	in which case, non-ironic? in that case you use $COMPUTE_NODE yeah?
14:58:12	efried	Yeah, I would think so. gibi, can we convince you we don't need identification by name?
14:58:23	efried	(I think it was gibi who talked us into it)
14:58:26	dansmith	either way,
14:58:46	dansmith	I'm not sure we really need to care that much if someone puts a thing in there twice
14:59:12	efried	right, you kinda f'ed up if that happens, but the code has to do *something* in that case.
14:59:21	dansmith	*if* we can detect and log an error later that's helpful, but..
14:59:34	dansmith	your concern is just not being able to detect that at startup?
14:59:40	efried	right.
14:59:51	gibi	efried: I'm sort on context. Is it about provider config?
15:00:05	efried	if we can detect it at startup, we can halt the service and force you to fix it. But we don't want to kill the service if it creeps in after we've already started running.
15:00:07	efried	gibi: yes
15:00:16	dansmith	efried: if it's hard/impossible to do at start, is clearly wrong config, and we can log an error later I think that's reasonable
15:00:29	dansmith	efried: no, don't halt.. log an error periodically
15:00:36	efried	dansmith: ack
15:00:41	gibi	efried: so in case of a compute RP the name is known before the compute was ever started but the uuid only known after the compute creates the RP
15:00:44	dansmith	we should never kill nova-compute after it's hit steady-state
15:00:48	efried	right
15:00:57	dansmith	gibi: we have $COMPUTE_NODE for that
15:01:05	efried	gibi: Right, in that case, we can use the special ``$COMPUTE_NODE`` ... yeah ^
15:01:07	gibi	dansmith: I see.
15:01:09	dansmith	they don't need to know either the name or the uuid for the compute node
15:01:33	gibi	so instead of allowing RP identification by name in general, we add a specific case for compute node
15:01:50	dansmith	we have that already
15:02:03	dansmith	uuid can be a uuid or the special string "$COMPUTE_NODE"
15:02:40	gibi	so far I'm OK with this. I guess if other RPs needs to be identified by name then we will add other symboles for that or we re-think the identify-by-name feature
15:02:41	dansmith	efried: note that I'm okay with either removing name, or just detecting and logging this case later
15:02:50	bauzas	gibi: dansmith: I haven't paid attention yet to this convo as I'm dragged into some internal all-hands but when I was looking on how to use the new COMPUTE_NODE trait, I think that we miss the world of nested RPs
15:03:11	bauzas	unless we have some way to have some traits to be cascaded into child RPs
15:03:24	bauzas	(and I really want to avoid saying 'inheritance')
15:03:59	bauzas	but for example, if you lookup some RP, you need to call the RP and check its trait to know whether the original RP is still related to a compute node
15:04:02	efried	bauzas: The only rp we're supporting this "wildcard" for right now is the root. If we find we need a way to generically identify its children later, we'll have more designing to do.
15:04:23	bauzas	you need to call the *root* RP
15:04:27	bauzas	(sorry for confusing)
15:04:40	dansmith	is bauzas talking about this same thing?
15:04:46	efried	almost :P
15:04:53	gibi	hm, the neutron device RPs (provising bandwidth) also has a stable name generated from the device name. But as I don't have a use case for provider config related to the bandwidth feature I rest my case.
15:05:01	bauzas	efried: sure, I'm just saying this is only convenient when you're in a flat world
15:05:26	efried	I agree. Predictably-named nested RPs make a case for identifying by name.
15:06:08	efried	though I think we've talked about the brittleness of relying on names before.
15:06:32	gibi	efried: we have predicatable named nested RPs | 1110cf59-cabf-526c-bacc-08baabbac692 | aio:Open vSwitch agent:br-test
15:06:55	mnaser	sean-k-mooney: sorry, was in a meeting too then, but no that wasnt enabled, but they are much older and also running ddr3 memory for comparision
15:07:02	mnaser	much lower latency but lower bandwidth
15:07:12	gibi	efried: but as I said I have no direct use case so I don't want to push for the naming support in provider config
15:07:14	sean-k-mooney	so that was cross socket latency
15:07:16	bauzas	efried: FWIW, we stecked a few things at the PTG between gibi, stephenfin and me that were tied to naming conventions :)
15:07:23	bauzas	we sketched*
15:07:24	efried	I know, what I'm saying is that we shouldn't have architected anything to rely on naming conventions, and we shouldn't perpetuate such things.
15:07:35	efried	but that ship has probably sailed.
15:07:37	mnaser	sean-k-mooney: yep!
15:07:37	sean-k-mooney	mnaser: i was trying to figure out if the intel number were between socket or two numa nodes in the same socket
15:07:43	bauzas	efried: indeed
15:07:49	sean-k-mooney	ya those latency numbers for amd are bad
15:07:54	mnaser	nope, between two sockets, which is interesting in just how much faster cross socket latency is low
15:08:21	efried	In any case, if gibi doesn't have any real, current bw use cases, and bauzas doesn't have any real, current vgpu use cases, I'm fine making the decision to remove identify-by-name to limit scope/complexity.
15:08:23	gibi	efried: there are things already architectured that way. like the hostname of the compute node is an id neutron use. and nova user the name of the device RP from neutron
15:08:24	mnaser	sean-k-mooney: im looking at the bios for the speed between the two sockets, i learned something about the amd architecture that doesnt seem ideal
15:08:41	efried	we've removed a lot of bells and whistles for that reason, just to make this go.
15:08:41	gibi	efried: agree with the limited scope
15:08:52	gibi	efried: go for it
15:08:56	bauzas	efried: it's not really a vgpu thingy
15:08:56	sean-k-mooney	so that lend more crednece to enableing numa per ccx and usign muiti numa guests
15:08:59	gibi	efried: we can always add that later
15:09:05	bauzas	efried: it's more what gibi said
15:09:08	efried	otoh, where I started this morning actually handles things including name pretty well IMO
15:09:19	bauzas	efried: some other projets create their own RPs and we need to know them
15:09:19	sean-k-mooney	mnaser: the fact the infity fabric speed used to be tied to the meory speed
15:09:20	efried	and dustinc has mostly already coded it up
15:09:26	efried	so it's really just a question of test surface
15:09:34	mnaser	sean-k-mooney: "By default, the BIOS for EPYC 7002 Series processors will run at the maximum allowable clock frequency by the platform. This configuration results in the maximum memory bandwidth for the processor, but in some cases, it may not be the lowest latency. The Infinity Fabric will have a maximum speed of 1467 MHz (lower in some platforms), resulting in a single clock penalty to transfer data from the
15:09:34	mnaser	memory channels onto the Infinity Fabric to progress through the SoC. To achieve the lowest latency, you can set the memory frequency to be equal to the Infinity Fabric speed. Lowering the memory clock speed also results in power savings in the memory controller, thus allowing the rest of the SoC to consume more power potentially resulting in a performance boost elsewhere, depending on the workload."
15:09:50	bauzas	efried: for the moment, we infer their existences based on naming convention but I'm all up for other ideas :-)
15:10:26	gibi	bauzas: a counter example is shared disk. there we said use the uuid of the placement aggregate instead of the name of the sharing RP in the nova conf.
15:10:34	sean-k-mooney	mnaser: ya so in gen 1 they were tied of the same clock
15:10:48	gibi	bauzas: so we are getting better at this
15:10:49	bauzas	gibi: aaaaaand we discussed 30 mins of any potential issues with it :)
15:10:56	dansmith	efried: reminder: I'm fine with logging the conflict late when the admin configured it wrong
15:11:02	sean-k-mooney	so your memroy bandwith was limited by the speed at which the infinity frabric could run
15:11:04	bauzas	the chicken-and-egg problem
15:11:10	dansmith	maybe nobody else is :)
15:11:13	gibi	bauzas: that is what PTG for. isn't it? ;)
15:11:21	sean-k-mooney	mnaser: they split them to allwo you to tune them seperatly
15:11:34	bauzas	gibi: that's surely some justification for my expense report, for sure :p
15:11:38	sean-k-mooney	mnaser: so you can optimise for latency or througput
15:12:05	efried	dansmith: That wfm too. The only question is, in addition to logging the error, we have to *pick one* to use.

Earlier   Later