| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-28 | |||
| 21:13:12 | efried | jaypipes Sure, I can do that. | |
| 21:13:26 | jaypipes | efried: ty | |
| 21:16:16 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Add trait support in the allocation candidates API https://review.openstack.org/497713 | |
| 21:16:22 | efried | jaypipes hecho ^ | |
| 21:16:42 | jaypipes | efried: danke | |
| 21:18:42 | cdent | i guess I better actually read that one | |
| 21:19:05 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix CellDatabases fixture swallowing exceptions https://review.openstack.org/506312 | |
| 21:19:05 | openstackgerrit | Dan Smith proposed openstack/nova master: Use improved instance_list module in compute API https://review.openstack.org/505418 | |
| 21:19:06 | openstackgerrit | Dan Smith proposed openstack/nova master: Move cell marker tests to Cellsv1DeprecatedTestMixIn https://review.openstack.org/508314 | |
| 21:19:06 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix minor input items from previous patches https://review.openstack.org/506416 | |
| 21:25:13 | efried | jaypipes Oh, did you mean https://review.openstack.org/#/c/468797/ ? I can update that one too... | |
| 21:25:30 | jaypipes | efried: that would be great, too. | |
| 21:25:37 | jaypipes | efried: that's the flavor changes, right? | |
| 21:25:51 | efried | They're different, mind you: one's in flavor and the other's in API. But with the current proposals I don't see any reason they shouldn't both be required= | |
| 21:26:10 | jaypipes | efried: agreed completely. they should match. | |
| 21:27:27 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Request traits in Nova https://review.openstack.org/468797 | |
| 21:27:34 | efried | jaypipes ^ | |
| 21:27:41 | jaypipes | efried: danke | |
| 21:27:46 | efried | bitte | |
| 21:30:12 | efried | jaypipes of Nederland als je wil | |
| 21:30:58 | jaypipes | efried: no. I speak only English. and badly at that. | |
| 21:32:39 | cdent | efried: I’m sensing a good deal of polylingualism in your direction | |
| 21:33:01 | efried | jaypipes Oh, I thought you had some Dutch, or Afrikaans. | |
| 21:33:07 | efried | cdent You could say I'm a cunning linguist. | |
| 21:33:40 | efried | If only I could learn python | |
| 21:34:57 | takashin | oomichi: Are you around? | |
| 21:37:43 | efried | cdent "The traits don't belong to the children do they, they just happen to be present because the parent is present. You can't have the trait without the parent, right?" <== talk to me | |
| 21:38:21 | efried | Any RP can have traits. The paragraph in question is talking about how traits inherit in a NRP tree and (not) in aggregates. | |
| 21:39:03 | efried | The paragraph is saying that a parent RP's traits implicitly also belong to its descendants, but not the other way around. | |
| 21:39:06 | cdent | a) how traits behave in rps is not relevant to that spec is it. That spec is merely saying “I require this trait”, so the paragraph is not required and merely confuses (it did me) | |
| 21:39:53 | efried | cdent Mm, I think it's relevant to understanding what you're expecting to get back when you specify those required traits. | |
| 21:40:20 | efried | And also how the implementor of the RPs should model them in order for that to be effective. | |
| 21:40:26 | cdent | it means you’ll get back some resource providers, one of which will have that trait, that’s all | |
| 21:40:32 | cdent | s/one/at least one/ | |
| 21:40:46 | efried | I believe that paragraph indicates that that is not completely true. | |
| 21:40:58 | cdent | explain? | |
| 21:41:11 | efried | Because I could get back a leaf RP that doesn't actually have the trait explicitly itself, but got returned because its parent/ancestor had that trait. | |
| 21:41:42 | cdent | and that’s my question: you’ll only see that leaf in the results if you are _also_ seeing the ancestor in the results | |
| 21:41:44 | efried | It's unclear (but needs to be clarified) whether the API is gonna populate the leaf RP's traits with all the ancestors' traits as it returns it. | |
| 21:42:19 | efried | Yeah, that's another good question: are you going to get back the parent RP in the response? If so, it's likely not to have any inventory allocated out of it. | |
| 21:42:26 | efried | is that kosher? | |
| 21:43:35 | cdent | that’s indeed a tricky question, because we’ve where a VCPU lives in a NUMA world ambiguous in our questions | |
| 21:44:06 | cdent | the early assumptions were it would be on the compute node instance (the ultimate parent of any tree returned in allocation_candidates) | |
| 21:44:24 | cdent | so there would always be inventory consumed at the top | |
| 21:45:05 | cdent | but even if inventory is not consume at the top we must have the resource provider uuid of the compute node so we know what the destination is | |
| 21:45:37 | edleafe | we are always returning root RPs, right? | |
| 21:45:47 | cdent | so even if the allocation part of the allocation candiate doesn’t consumer, there will be a record in the other half of the tuple which has the roots | |
| 21:45:59 | edleafe | IOW, we'd never return a NIC by itself | |
| 21:46:04 | cdent | edleafe: i think so, yes, at least in the resource providers half of the tuple | |
| 21:46:06 | efried | More recently we've talked about modeling NUMA by making the NUMA nodes child RPs and having them provide the CPU/MEM(/possibly-other-things-like-PFs) resources. | |
| 21:46:17 | cdent | efried: right, but they are still a child | |
| 21:46:32 | cdent | so you could alloc against them, but still _place_ on the parent | |
| 21:46:32 | efried | Well, okay, but if the tree is three deep, the root RP may still not have the traits the leaf is inheriting. | |
| 21:46:52 | cdent | I think inheritance is a very bad way of thinking of this | |
| 21:46:59 | cdent | and that’s what my comment was inspired by | |
| 21:47:04 | cdent | (on the review) | |
| 21:48:07 | cdent | which spec has allocation candidates? | |
| 21:48:38 | edleafe | cdent: yeah, this is more like composition than inheritance | |
| 21:49:00 | cdent | ah, it’s got the wrong name: http://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/placement-allocation-requests.html | |
| 21:49:25 | dansmith | gah | |
| 21:49:31 | dansmith | 403 Forbidden: You are not authorized to complete publicize_image action. (HTTP 403) | |
| 21:49:31 | dansmith | does anyone else get stopped in devstack doing this? | |
| 21:49:50 | dansmith | must be residue leftover from my previous install, but I don't know what it is | |
| 21:50:35 | cdent | efried: in there, provider_summaries is the second half of the tuple, contains the rp info. in there will be represented the info to construct a nested provider hierarchy, I don’t know if that’s defined yet | |
| 21:50:56 | cdent | efried: but in that a trait will be on the thing to which the trait was associated, not its children | |
| 21:51:30 | efried | cdent You could totally return *just* the RPs that are being claimed against, and the scheduler would have to use the root RP UUID to pull the whole tree from placement at that point. | |
| 21:52:10 | efried | Or you could return the whole tree, and the scheduler would not have to do that, but there would be empty "allocations". | |
| 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. | |