| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 14:23:16 | mriedem | stephenfin: keeping in mind we need to backport whatever the changes are | |
| 14:23:29 | mriedem | so maybe step 1 is just import the user guide docs and backport, then step 2 is re-arrange and clean them up | |
| 14:23:36 | mriedem | since some of the config drive user guide docs are really for admins | |
| 14:23:44 | bauzas | jaypipes: but I had the same concern without traits, say I have 2 children with each of them having 8 FOOs | |
| 14:23:46 | jaypipes | bauzas: but remember that the max_unit/min_unit part of hte inventory records will solve that query problem. | |
| 14:23:57 | stephenfin | mriedem: I was going to, but Takashi NATSUME (I don't know his IRC nick) might be on it | |
| 14:24:12 | bauzas | jaypipes: if I'm asking for 9 FOOs, I wouldn't get them even if I could have 8 in a child and 1 in the other child | |
| 14:24:14 | stephenfin | see https://bugs.launchpad.net/nova/+bug/1720873 | |
| 14:24:15 | openstack | Launchpad bug 1714017 in OpenStack Compute (nova) "duplicate for #1720873 User guide was not migrated to the nova repo" [Medium,In progress] - Assigned to Pavlukhin Max (mpavlukhin) | |
| 14:24:38 | bauzas | jaypipes: mmm, I don't see how that helps but okay :) | |
| 14:24:48 | jaypipes | bauzas: if you request 9 foo and there are 2 child providers having 8 foo inventories, each of those inventory records would have max_unit = 8 and that would mean a failing WHERE condition on max_unit <= $requested_amount | |
| 14:25:11 | bauzas | jaypipes: I certainly understand *why* it's failing | |
| 14:25:32 | bauzas | jaypipes: but I can easily imagine operators asking for spreading their resources | |
| 14:25:34 | efried | yeah, that's a bug. | |
| 14:25:34 | mriedem | stephenfin: ok | |
| 14:25:50 | stephenfin | If they haven't done anything by next week, I'll pick it up | |
| 14:26:14 | bauzas | snap, I need to disappear for my daily daddy work | |
| 14:26:24 | jaypipes | bauzas: sorry, I'm not following you still. :( | |
| 14:26:26 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Move 'ips' field from Subnet object to VIF object https://review.openstack.org/508498 | |
| 14:27:21 | jaypipes | efried: do you think bauzas is talking about the resources1=, required1= stuff we discussed at the PTG? | |
| 14:28:34 | stephenfin | jaypipes: Fancy taking a look at this some time today? https://review.openstack.org/#/c/502056/ | |
| 14:28:39 | stephenfin | (it's docs) | |
| 14:29:31 | efried | jaypipes A side effect thereof, yes. | |
| 14:30:14 | efried | jaypipes bauzas The two scenarios starting on L83 here: https://etherpad.openstack.org/p/nova-multi-alloc-request-syntax-brainstorm | |
| 14:30:33 | efried | ...as far as spreading resources across RPs. | |
| 14:32:45 | jaypipes | efried: ok. I don't disagree that any of those scenarios are important. just that it's kind of a distraction at this point and an acknowledged thing we'll need to look at at a later time | |
| 14:33:52 | efried | For the other discussion - how do traits "propagate" - perhaps it should be phrased: "With nested resource providers, traits defined on a parent RP are assumed to belong to all its child (descendant) RPs >>for purposes of inventory allocation<<. Traits defined on a child RP do not apply to the parent (ancestor) RPs. >>Although inventory is only claimed from a RP having the requested traits, the entire RP tree is returned in the provider summary for | |
| 14:33:52 | efried | that allocation candidate.<<" | |
| 14:34:00 | efried | or something like that. | |
| 14:35:48 | cdent | 🤐 | |
| 14:36:36 | efried | cdent Glad you're staying out of it. | |
| 14:37:30 | efried | bauzas jaypipes We may want to defer this discussion; replace that chunk with "how traits are handled in nested RPs is out of scope and will be discussed in a subsequent spec". But that spec needs to land in Queens. | |
| 14:37:47 | sdague | melwitt: https://review.openstack.org/#/c/486947/ is a quotas spec that would be great to have your commentary on | |
| 14:38:06 | efried | jaypipes The "numbered resources querystring" spec would be a reasonable place for that discussion. | |
| 14:39:00 | mriedem | dansmith: you should probably go through this https://review.openstack.org/#/c/433603/ | |
| 14:39:32 | dansmith | mriedem: ugh, do I have to? | |
| 14:39:53 | mriedem | yes | |
| 14:39:59 | mriedem | and finish your peas | |
| 14:40:30 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Network bandwitdh resource provider https://review.openstack.org/502306 | |
| 14:42:59 | efried | jaypipes How does the scheduler determine that a particular RP is a compute host for the purposes of landing an instance? | |
| 14:43:26 | efried | (Yes, this is ultimately relevant to the discussion) | |
| 14:45:11 | jaypipes | efried: right now, the scheduler has a mapping of hostname to compute node UUIDs. the hostname is the same as the nova-compute service RPC topic queue | |
| 14:45:33 | dansmith | mriedem: gawd moooom | |
| 14:45:55 | jaypipes | efried: https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L640 | |
| 14:46:14 | efried | jaypipes Okay, cool. Cause when we have more than just compute host RPs, that's going to be pretty crucial. | |
| 14:46:26 | jaypipes | efried: we already do... | |
| 14:46:49 | jaypipes | efried: Ironic nodes and shared storage providers are not compute nodes. | |
| 14:47:22 | efried | jaypipes Nested, then. Where that ties in is, you'll get your inventory from the child RP, but the whole tree is going to be (explicitly or implicitly via root_provider_id) part of your provider summaries. That's going to have to be how the scheduler figures out which compute node it should go to. | |
| 14:48:04 | mriedem | cdent: L105 here https://review.openstack.org/#/c/506552/4/specs/queens/approved/allow-update-instance-keypair.rst | |
| 14:48:10 | mriedem | PUT /servers/{server_id/ | |
| 14:48:14 | efried | jaypipes Cause at some point, there's gonna be a model where the compute node RP actually doesn't have *any* resources (e.g. VCPU and MEMORY_MB belong to NUMA node RPs under the compute host; DISK_GB belongs to a shared RP somewhere; etc.) | |
| 14:48:25 | mriedem | if the server is not found by id, it's a 404, but if something in the request body isn't found, then it's a 400, right? | |
| 14:48:37 | cdent | mriedem: correct, that’s the general rule | |
| 14:48:46 | jaypipes | efried: the allocation_requests part of the GET /allocation_candidates HTTP response has the exact allocations against the exact resource providers that the instance will consume from (compute node providers and otherwise) | |
| 14:48:53 | cdent | if the uri fails to hit, 404, otherwise 400 | |
| 14:50:01 | efried | jaypipes Right, but see above (..:48:16). The compute host RP may not actually be in the list of exact RPs the instance will consume from). | |
| 14:50:26 | mriedem | sdague: i see you found the competing instance keypair update specs | |
| 14:50:32 | mriedem | and i know you saw the ML thread | |
| 14:50:52 | mriedem | what i don't know is what most deployments do about cloud-init behavior | |
| 14:51:03 | mriedem | if they refresh on reboot or only on new build | |
| 14:51:04 | jaypipes | efried: the compute node provider will always be the root_provider_id, though. | |
| 14:51:39 | efried | jaypipes Right. That's my point. Generically, the scheduler will have to find the compute host by backtracking to the root_provider_id. | |
| 14:51:44 | jaypipes | efried: and the provider_summaries part of the GET /allocation_candidates HTTP response informs the caller that a particular provider is a child of another. | |
| 14:52:05 | jaypipes | efried: yes, that is true. | |
| 14:52:11 | jaypipes | efried: and expected. | |
| 14:52:26 | efried | jaypipes Right. That's another question I've had, though: will provider summaries include the whole tree, or only the "exact resource providers that the instance will consume from"? | |
| 14:52:33 | jaypipes | efried: the placement doesn't know or care that a particular provider represents a compute node. | |
| 14:52:49 | efried | right - the scheduler has to figure that out, I get that. | |
| 14:53:01 | efried | hence my original leading question. | |
| 14:53:02 | jaypipes | efried: placement doesn't care about anything other than inventory and allocation records... | |
| 14:53:16 | jaypipes | efried: so it's the scheduler's responsibility to understand those things. | |
| 14:53:24 | efried | Yup. | |
| 14:53:52 | jaypipes | efried: currently, the scheduler does that by keeping that map of service RPC to compute node UUID in memory. It will need to be adapted to understand nested/root providers | |
| 14:54:12 | efried | jaypipes Will provider summaries include the whole tree, or only the exact RPs being consumed from? | |
| 14:54:38 | jaypipes | efried: the exact RPs that could be consumed from and their parents. | |
| 14:54:50 | jaypipes | efried: which is needed for callers to piece the tree together. | |
| 14:54:50 | efried | parents/ancestors | |
| 14:54:53 | jaypipes | yes | |
| 14:54:54 | efried | up to the root | |
| 14:54:57 | jaypipes | yes | |
| 14:54:57 | efried | okay. | |
| 14:55:16 | efried | I dig that. Saves an extra call from the scheduler. | |
| 14:55:28 | jaypipes | efried: I wasn't planning on making provider_summaries into a tree structure, though. was relying on the caller to do that as needed. | |
| 14:56:04 | efried | I don't see the need for the whole tree - except that's easier to build, cause you'll already have that code for that API (forget which one) that returns a whole tree. | |
| 14:56:28 | efried | The chain of parents is simple enough, but a separate algorithm. | |
| 14:56:30 | bauzas | efried: jaypipes: sorry I had to disappear due to family business | |
| 14:56:46 | bauzas | but yeah let's punt that discussion | |
| 14:57:00 | jaypipes | bauzas: commented on the spec. | |
| 14:57:19 | ralonsoh | jaypipes: hello. About https://review.openstack.org/#/c/502306/2/specs/queens/approved/bandwidth-resource-provider.rst@111. I don't understand what you mean. Should ML2 plugin be able to make RP claims? Or create/delete allocation records? | |
| 14:57:35 | bauzas | the thoughts that I had was about saying "what if I'm asking for more than the inventory amount supported by one child" | |
| 14:57:46 | cdent | jaypipes: I just had a quick confused run through there. Looks like some fundamental misconceptions. | |
| 14:58:05 | jaypipes | ralonsoh: heh, I was just making a joke about the repeated misspellings of the word "bandwidth" :) | |
| 14:58:16 | ralonsoh | jaypipes: sorry! | |
| 14:58:18 | jaypipes | Including in the spec title ;) | |
| 14:58:29 | jaypipes | ralonsoh: it's cool, I'm just kidding with ya | |
| 14:59:13 | jaypipes | cdent: "Horse". | |
| 14:59:41 | cdent | such disappoint | |
| 14:59:51 | jaypipes | ralonsoh: I'll comment on the spec, k? | |
| 15:00:00 | ralonsoh | jaypipes: perfect! and thanks | |
| 15:00:06 | jaypipes | ralonsoh: no problemo | |