| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-28 | |||
| 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 ++ | |
| 22:40:45 | cdent | so should many things :) | |
| 22:41:14 | efried | But given that we did the comma thing, IMO the lesser evil is consistency and KISS. | |
| 22:42:44 | cdent | On 2) above, I’m less worried about people creating flavors than I am about inventory creating tooling getting the traits on the righ resource. Because in a flavor when you express a trait or quantity of resource, initially, it’s just that you require it, not the structure thereof | |
| 22:43:06 | cdent | the comma thing will remain the primary thing I expect | |
| 22:43:19 | mikal | mriedem: ok, I will do that thing | |
| 22:43:30 | cdent | and we may never do the repeat thing, unless the framework already supports it (which it may, which is why I mentioned it) | |
| 22:43:51 | mriedem | mikal: thanks | |
| 22:45:01 | cdent | is extra_specs a dict, or is it a string that looks vaguely like a dict? | |
| 22:48:23 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use ksa adapter for cinder client (OPTION 1) https://review.openstack.org/508345 | |
| 22:53:05 | mriedem | johnthetubaguy: if you're going to be at the forum: http://forumtopics.openstack.org/cfp/details/12 | |
| 23:00:41 | mriedem | i've seen at least 3 forum topics on here about ETSI/NFV | |
| 23:00:45 | mriedem | all sound like duplicates | |
| 23:00:54 | mikal | You're welcome? | |
| 23:01:51 | mriedem | "HOT topic: Heat-ing up Telco VNFs in the ETSI way" | |
| 23:01:57 | mriedem | this guy knows how to get a talk accepted | |
| 23:02:36 | mikal | As a man who recently learned those acronymns, isn't that just a session on how to use heat to start instances? | |
| 23:05:01 | mriedem | ha | |
| 23:05:04 | mriedem | maybe? | |
| 23:05:10 | mriedem | but in the etsi way | |
| 23:06:37 | cdent | MANO your VIM with TOSCA | |
| 23:07:15 | jaypipes | dansmith: so after 4 hours fucking around with this, I remember why I made it parent_provider_uuid and root_provider_uuid instead of using internal integer fields. | |
| 23:07:28 | dansmith | jaypipes: lay it on e | |