| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 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 | |
| 15:00:32 | mriedem | stephenfin: you've made the diff on this impossible https://review.openstack.org/#/c/496160/ | |
| 15:00:37 | mriedem | to compare to the pike spec | |
| 15:00:55 | mriedem | stephenfin: if you're re-proposing a spec from a previous release, please leave the stylistic changes for a separate patch | |
| 15:00:55 | stephenfin | mriedem: How so? | |
| 15:01:04 | mriedem | you change all the line wrapping | |
| 15:01:33 | mriedem | i think you are going to need to setup a dr visit about your serious ocd issue | |
| 15:02:15 | jaypipes | wait... mriedem is calling someone ocd? | |
| 15:02:22 | cdent | my thoughts exactly | |
| 15:02:24 | stephenfin | mriedem: Ah, I can undo those, but the only functional changes are the things that were already commented on | |
| 15:02:26 | jaypipes | :P | |
| 15:04:36 | mriedem | stephenfin: already approved | |
| 15:04:38 | mriedem | but for next time | |
| 15:04:52 | stephenfin | mriedem: (y) | |
| 15:05:26 | mriedem | jaypipes: i'm not the one that -1s your changes for putting closing ] and } and ) on separate lines :P | |
| 15:05:44 | jaypipes | mriedem: lol, tru dat | |
| 15:05:59 | jaypipes | mriedem: that would be edleafe and dansmith, or as I call them "The Parens Posse" | |
| 15:09:32 | cdent | dan’s down with tpp | |
| 15:09:54 | cfriesen | tpp ya you know me... | |
| 15:10:03 | sdague | mriedem: yeh, I don't know either | |
| 15:10:25 | sdague | also, I think there is lots of confusion about "rebuild" | |
| 15:10:41 | sdague | because even in the ML thread where someone said "yes, this would be great!" | |
| 15:10:56 | sdague | and I asked "on just rebuild or you want reboot", A: "we never use rebuild" | |
| 15:11:31 | mriedem | i'm trying to get some more answers in the ops channel | |
| 15:11:49 | mriedem | and the answer i'm getting there is, "we don't use cloud-init to manage keys in the guest" | |
| 15:12:21 | sdague | um... so huh what? | |
| 15:12:41 | sdague | mriedem: joined there late, who said that? | |
| 15:12:44 | mriedem | bloomberg runs a script which is in the image that refreshes the users for the vm, or something | |
| 15:12:54 | mriedem | mihalis68 | |
| 15:13:01 | sdague | yeh, cool, so they don't use the keypairs api then | |
| 15:13:15 | sdague | which, honestly, makes sense | |
| 15:13:16 | jaypipes | mriedem: probably they mean there's a single key they use for chef and then rely on chef to inject/write other user keys. | |
| 15:13:25 | sdague | do the whole thing out of band | |
| 15:14:26 | mriedem | cburgess: do you have input on this keypair update thing? do you configure cloud-init in the images to refresh keys on reboot or only new build of the guest? | |
| 15:15:13 | sdague | mriedem: I think the question probably should be A) do you regularly use the keypairs api | |
| 15:15:14 | mriedem | basically what i don't like about Kevin's spec is the 2-3 step dance, which varies from cloud to cloud based on how cloud-init is configured in the image | |