| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-28 | |||
| 21:52:11 | cdent | you could, yes, but I don’t think that was the plan. I suggested at one point we should just return uuids and require the client to go back for more info if it wanted | |
| 21:52:26 | cdent | why would there be empty allocations? | |
| 21:52:26 | efried | Or you could return just the claimed RPs in the allocations, but return the whole RP trees in the provider summaries. | |
| 21:52:51 | cdent | the structure in provider_summaries is not directly mapped to what is in allocations | |
| 21:52:54 | mriedem | dansmith: making an image public? | |
| 21:53:06 | mriedem | but devstack uploads the image... | |
| 21:53:07 | dansmith | mriedem: that's just during stack | |
| 21:53:43 | efried | dansmith Could be perms in your configured temp dir, which glance uses to store a copy of the image while it's uploading it. | |
| 21:54:02 | dansmith | efried: I dunno what would have changed from one stack run to another | |
| 21:54:07 | cdent | efried: so I’m still confused about how/why you want inheritance to be a thing | |
| 21:54:33 | efried | cdent Lemme find that conversation. It's in the same spec, same area, earlier rev... | |
| 21:54:34 | dansmith | mriedem: efried: this is a centos box and my best guess is that clean.sh doesn't clean something for redhat systems like it does for ubuntu or something | |
| 21:54:41 | dansmith | guess what I'm doing right now? | |
| 21:55:05 | mriedem | umm | |
| 21:55:23 | efried | cdent PS6 | |
| 21:55:37 | efried | cdent There's an example there | |
| 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 :) | |