Posted	Nick	Remark
#openstack-nova - 2017-09-28
22:01:24	efried	In this example, the NUMA node and the compute node are *different* RPs.
22:02:01	cdent	I agree that we need to be crisp, which is why I’m disputing the use of the term “inherited” it’s misleading
22:02:03	efried	If I ask for inventory on a resource class, I should only get a RP that has inventory in that resource class. If I ask for a required trait, I should only get a RP that has that trait.
22:03:10	efried	In this case, I'm asking for e.g. CPU inventory, which belongs to the NUMA node (not the compute host). And I'm asking for trait HW_CPU_MAGIC_CACHE_THINGY, which belongs to the NUMA node (not the compute host). So far so good.
22:03:25	efried	But then I'm *also* asking for trait HW_CPU_X86_SSE2.
22:03:38	efried	That trait belongs to the compute RP but *not* the NUMA node RP.
22:04:10	efried	So by the rules, with no "inheritance" (or whatever you wanna call it), that request would kick out the NUMA node RP because the NUMA node RP doesn't have the HW_CPU_X86_SSE2 trait.
22:04:59	efried	If we want to do it that way, it's possible, but it means the implementor who models the RPs would have to *duplicate* the HW_CPU_X86_SSE2 trait (and all those other CPUey traits) onto each NUMA node RP.
22:05:24	efried	jaypipes put a stake in the ground and said we could inherit downward, which is why we needed to make this statement in the spec.
22:06:09	efried	Based on your confusion, though, it seems like we would have done well to include the example, as well as listing the no-inheritance-but-duplication thing in Alternatives.
22:07:23	cdent	I guess maybe I’m too embedded but the statement is a) obvious, b) not inheritance. It is simply that you “got” the compute node, because you asked for that trait
22:07:41	cdent	it’s not that the numa node has that trait by inheritance
22:07:44	efried	But I don't want the compute nod.
22:07:46	efried	node
22:07:48	cdent	you do
22:07:52	cdent	you _have_ to have the compute node
22:07:53	efried	I'm not claiming any inventory off of it.
22:07:55	cdent	it is your destination
22:08:25	cdent	it is the place where your inventory is
22:08:27	efried	Meh, that's kind of an artifact of the root RP happening to be a compute node.
22:08:42	efried	cdent Ah, so wait, that's where we're disagreeing I think.
22:08:51	efried	The compute node RP is *not* where your inventory is.
22:08:58	efried	The NUMA node RP is where your inventory is.
22:09:31	efried	Unless you're saying the compute node inherits (accumulates? composes?) the inventory from its descendants.
22:09:33	cdent	which is “within” the copute node, by representation (even if it happens to be only logically so)
22:10:14	cdent	nested providers are nested
22:10:38	cdent	and they are generally created when a compute node does get_inventory
22:10:56	efried	Right. So inventory is implicitly crossing RP boundaries (you don't like the word "inheritance"; fine; pick another word). The disputed statement is saying traits do the same.
22:11:19	efried	Also trying to think not totally compute-node-is-the-root-RP-centric
22:11:27	cdent	I’m saying it’s not relevant when requesting allocation_candidates to know that
22:11:40	cdent	(that being “traits compose”)
22:13:08	efried	I'm coming from, "it is relevant, both from the perspective of the requestor and the perspective of the implementor of the RP models being looked at by the allocation_candidates API." Let me think through it again...
22:14:28	cdent	If we’re trying to be crispy, then the crispiness I’m trying to go for in the example is that we shouldn’t say “the numa node is HW_CPU_X86_SSE2” when it is the parent that has that trait
22:15:30	efried	Then we would have to duplicate the trait on each NUMA node.
22:15:59	cdent	that’s what I’m not understanding. How are you reaching that conclusion?
22:16:33	efried	In this case I'm assuming the resources themselves are owned by the NUMA node RPs. Not by the compute node RP.
22:16:43	efried	GET /allocation_candidates?resources=VCPU:1,required=HW_CPU_X86_SSE2,HW_CPU_MAGIC_CACHE_THINGY
22:17:51	efried	I haven't gotten the impression that we're supposed to return allocations that satisfy any permutation of that request. I've gotten the impression we're supposed to return allocations that satisfy *all* of those criteria.
22:18:13	cdent	well, not to draw us off into the weeds too far, but if you’re going to put the VCPU inventory on a numa node, then presumably you put the hw traits of cpus on the numa node too?
22:18:26	cdent	ignore that
22:18:30	efried	Ah, that's the point of contention. jaypipes said (in PS4)... okay.
22:19:00	cdent	I agree that we should only satisfy all those criteria
22:19:44	efried	Okay. Then as modeled, without "inheritance", we would get nada back from that request.
22:20:00	efried	because there isn't a single resource provider that satisfies all of it.
22:20:21	cdent	so perhaps you are using the term “inheritance” to mean something like “which direction in the resource provider tree should would look to see if a trait is available”?
22:20:28	cdent	up, down, both
22:20:31	cdent	and you’re saying only up
22:20:31	jaypipes	efried: I also said in PS4 that I disagreed with you calling it inheritance. :)
22:20:53	cdent	if “only up” then cool, but don’t use the term inheritiance :)
22:20:56	efried	bah, let's come up with a word for it that isn't "inheritance" so we can stop getting distracted by that. What do we call it.
22:21:08	jaypipes	propagation.
22:21:12	efried	cool.
22:21:15	cdent	is my description of “only up” what you mean?
22:21:19	efried	Traits propagate down.
22:21:22	efried	"only down".
22:21:29	efried	If parents are "up" and children are "down".
22:21:40	cdent	“looking from the thing with inventory, we only look up for missing traits"
22:21:53	efried	yes
22:21:54	efried	or
22:22:00	efried	"traits propagate down"
22:22:16	cdent	that means too much
22:22:40	cdent	because that means the same thing I was disagreeing with before: the children “get” the traits, they don’t
22:22:47	openstackgerrit	Matt Riedemann proposed openstack/nova master: Stop joining on system_metadata when listing instances https://review.openstack.org/508335
22:22:47	efried	RP do not apply to the parent (ancestor) RPs."
22:22:47	efried	belong to all its child (descendant) RPs. However, traits defined on a child
22:22:47	efried	What about, "traits defined on a parent RP are assumed to
22:23:02	mriedem	dansmith: when you get numbers ^
22:23:29	dansmith	mriedem: sorry I'm still fighting devstack
22:23:32	jaypipes	efried: isn't that essentially what I said ++ to on the patch?
22:23:34	cdent	“required traits which are not present on child can be satisfied by a parent” is much closer to the truth, I think? jaypipes ?
22:23:37	jaypipes	efried: that wording...
22:23:42	efried	jaypipes It's *exactly" that :)
22:23:45	mikal	Sorry I missed the meeting, I was at the doctor complaining that one of my ears has stopped working.
22:23:46	efried	Copied and pasted :)
22:23:49	jaypipes	right.
22:23:57	mriedem	dansmith: that's fine, i'm also going to check the n-api logs to see if anything gets lazy-loaded incidentally
22:24:37	efried	cdent I think saying "can be satisfied by a parent" implies more than what's happening.
22:24:44	cdent	jaypipes, efried : it’s the belonging thing that’s really botherin gme
22:25:07	cdent	but again, I’m not sure it is relevant in the immediate sense
22:25:11	cdent	(of the spec)
22:25:19	efried	okay, so back to that.
22:26:28	mikal	mriedem: does "Michael runs with this" mean you'd like me to propose the session?
22:27:10	efried	I assume the target audience of this spec is 1) developers who will be a) implementing the /allocation_candidates API changes, and b) coding the modeling and registration of the RPs that it'll talk to; as well as 2) (eventually, as it gets "propagated" into docs) the operator who's gonna populate the flavor with the resource classes and traits.
22:27:18	cdent	efried: If you want we can probably just revisit this later, as I’m +1. I’m conscious however that we will stumble on this stuff again later when trying to document stuff and consider implications.
22:29:41	efried	1a definitely needs to understand it for NRP to construct the query right. 1b needs to understand it for NRP to model the RPs right. And 2 needs to understand it because he's gonna look at the RPs as real things with meaningful traits and know that he can ask for HW_CPU_X86_SSE2.
22:30:40	efried	cdent Okay, sure. I don't necessarily disagree that the propagation discussion could have happened in a different spec as well (like maybe the NRP spec). But I still can't see how it's misplaced here.
22:32:36	efried	cdent Slightly less controversial (hopefully) response to your other comment inline :)
22:32:44	cdent	I don’t think it is misplaced, if it were clear, but it isn’t it, and clarifying it it is too hard especially when not in the context of the nrp spec/code, so as it is stands is distracting
22:33:49	mriedem	mikal: yes
22:34:52	efried	cdent Gotcha.
22:38:47	cdent	efried: yeah, I didn’t mention the resource3,required3 thing there because of wanting to keep the immediate scope narrow, but yes, both of those could also do the repeat treatment if we wanted. not necessary or anything
22:39:24	efried	cdent But don't we already have an API that does resources= with commas?
22:39:43	cdent	yes, but that doesn’t prevent also allowing repeats
22:39:52	cdent	that’s what I was saying, we can do both if we like
22:39:58	efried	Mm.
22:40:03	efried	That's a big test matrix
22:40:25	cdent	sure, but repeats is _normal_ for web-based query parameters, and we might like that
22:40:32	efried	I mean, I dig the idea of using the repeats. But seems like that's something that should have been done from the start.
22:40:38	cdent	oh sure
22:40:44	efried	Yeah, normal for web-based query params ++

Earlier   Later