Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-09-28
21:56:30 efried cdent And more background in PS4
21:56:40 efried ...which is where jaypipes actually provided the example
21:57:55 cdent that’s no inherited, the trait still matched on the compute rp, we _also_ got numa node 1 because we required magic cache thingy
21:58:31 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove old compat code from servers ViewBuilder._get_metadata https://review.openstack.org/508326
21:58:52 cdent the compute rp is a member of the results
21:59:02 efried cdent But with no inventory.
21:59:11 efried no inventory consumed* that is
21:59:35 cdent if it were not a member of the results, then that would be inheritance
22:00:05 efried But we need to be crisp about this because when we start doing the "grouping" thing, it's going to be important to be able to say that you *don't* get results that *don't* have your traits for a given group.
22:00:08 efried I said that horribly.
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.

Earlier   Later