| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-12 | |||
| 20:27:54 | efried | mriedem: Which, update_provider_tree? I don't think there's any possible interpretation by which that stack of work could be considered just "implementation detail". | |
| 20:27:54 | cdent | thanks edleafe enqueued for tomorrow, currently writing my own | |
| 20:28:38 | mriedem | efried: ok, i guess i need to read your provider tree spec then | |
| 20:28:51 | mriedem | which i thought you said was less of a spec and more just docs of the thing that merged in queens? | |
| 20:29:06 | efried | ...which needed to be specified in some form, yeah. | |
| 20:29:38 | efried | And which didn't quite get finished in queens, and is a big enough piece of work to warrant a bp and spec of its own (at least if it wasn't going to be described in the nrp spec) | |
| 20:31:55 | mriedem | ok, i'll get to new business some other day; was just trying to go through easy re-approvals | |
| 20:32:11 | mriedem | i will mentally note that this isn't an easy re-approval | |
| 20:32:50 | efried | mriedem: Anyway, to tie that back together, I believe update_provider_tree changes the NUMA plan as described around https://review.openstack.org/#/c/505209/7/specs/queens/approved/nested-resource-providers.rst@136 | |
| 20:34:08 | efried | mriedem: Because we're no longer going to be basing anything on get_available_resource. Rather, we'll ask virt to report NUMA topology through update_provider_tree (in some standardized format TBD? Swhat jaypipes and I are debating in https://review.openstack.org/543062) and then deal with the pinning/affinitizing from there. | |
| 20:34:42 | efried | Suspect there will be much PTGing at the PTG about this. | |
| 20:35:01 | mriedem | ok - thinking again about just amending the queens spec, making a note that the spec is just focusing on groundwork stuff, might give examples of use cases, but details for supporting other use cases (sriov/numa) are going to be found in later specs | |
| 20:35:30 | efried | mriedem: Do you want me to propose that edit? | |
| 20:35:36 | mriedem | up to you | |
| 20:35:37 | efried | Do we do that? | |
| 20:35:49 | mriedem | sometimes if things changed quite a bit | |
| 20:35:59 | mriedem | the thing i wouldn't want to say is, | |
| 20:36:16 | mriedem | the nrp spec is marked 'implemented' for queens and it says 'we'll model sriov with this in queens' and then we didn't | |
| 20:36:44 | mriedem | if we aren't going to re-propose the nrp spec for rocky because it's basically done and the rest is some other new spec, then we should say it was just done in queens | |
| 20:36:48 | mriedem | and amend accordingly | |
| 20:36:58 | efried | mriedem: Okay, well, the spec does say the NUMA/SR-IOV stuff won't be done in Q. | |
| 20:37:09 | efried | But it also asserts pretty forcefully what that will look like when it does get implemented. | |
| 20:37:51 | mriedem | the goal in queens was sriov | |
| 20:37:55 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html#work-items | |
| 20:38:09 | mriedem | "Please note that not all of this spec is expected to be implemented in a single release cycle. At the Queens PTG we agreed that fully suppporting NUMA will probably have to be deferred to the next release." just came out of the ptg saying we wouldn't try to get numa done | |
| 20:38:15 | mriedem | which implies sriov would be supported in queens | |
| 20:47:05 | efried | which is kind of a wow, because we're not even close to supporting SR-IOV. It's more than just NRP that needs to be wrapped up to make that happen. | |
| 20:48:12 | efried | mriedem: Softening those statements jeeest a leetle bit would make them more or less true: "...the ability to *model* NUMA and SR-IOV..." | |
| 20:48:33 | efried | You can model it. You just can't *do* anything with that model. | |
| 20:49:03 | efried | And you can't actually model it without writing more code on the nova side; but the placement side will handle it. | |
| 20:49:20 | efried | Except for the GET /allocation_candidates thing, which is required if it's going to be usable at all. | |
| 20:49:41 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nested-resource-providers.html#rest-api-impact | |
| 20:49:42 | efried | So yeah, it's a mess. | |
| 20:49:45 | mriedem | "The filter parameter root={uuid} will not be added to GET /allocation_candidates, as this call is for a specific use case for the Nova scheduler, and there is no use case for it." | |
| 20:50:07 | efried | Still true. | |
| 20:50:19 | mriedem | i think the nrp spec is mostly just about the modeling and placement api bits, | |
| 20:50:40 | mriedem | i think it's fine to say nova's usage of it for certain use cases (sriov/numa) are separate efforts that will build on this later | |
| 20:50:47 | efried | But GET /allocation_candidates - the algorithm on the back end - needs to be updated to understand and handle nested providers. Today it doesn't. If you have a tree model, you get no candidates. | |
| 20:51:12 | mriedem | sure, that's a new work effort | |
| 20:51:15 | efried | That's something that's not mentioned at all, but needs to be, and needs to be completed in Rocky ASAP. | |
| 20:53:03 | mriedem | so skimming over the spec again, it seems like if one just removed (or somehow re-worded) the parts about the scheduler reporting client in nova, it would explain what was completed in queens | |
| 20:53:11 | mriedem | agree? | |
| 20:53:32 | mriedem | add root_provider_uuid and parent_provider_uuid to GET /resource_providers, fin | |
| 20:54:04 | mriedem | .. note:: Future work will be needed client-side to model things like SR-IOV and NUMA for nova to leverage the Placement API for nested resource providers. | |
| 20:54:24 | efried | and ?tree= to the latter (written as ?root= in the spec, was renamed during impl) | |
| 20:54:57 | mriedem | you mean ?in_tree? | |
| 20:55:00 | mriedem | bazinga! | |
| 20:55:33 | mriedem | yeah so amend the ?in_tree thingy (we still haven't defined how that filter works i don't think) | |
| 20:55:46 | mriedem | remove/reword the parts about the scheduler client - say those are done separately later | |
| 20:55:49 | efried | fusque | |
| 20:55:55 | mriedem | and i think we say the rest is done in queens | |
| 20:56:08 | mriedem | with caveats like the GET /allocation_candidates thing | |
| 20:56:09 | efried | Oh, we nailed down in_tree. It's implemented. | |
| 20:56:36 | mriedem | i know it's in the api | |
| 20:56:46 | mriedem | but the semantics of how that works is not documented anywhere as far as i know | |
| 20:56:56 | mriedem | i remember bringing this up in a review or the ML or something at one point | |
| 20:57:22 | mriedem | https://review.openstack.org/#/c/520663/9/nova/tests/unit/scheduler/client/test_report.py@1400 | |
| 20:57:34 | efried | https://developer.openstack.org/api-ref/placement/#list-resource-providers | |
| 20:57:50 | mriedem | yeah i know about that, all it says is "A UUID of a resource provider. The returned resource providers will be in the same “provider tree” as the specified provider." | |
| 20:58:23 | jaypipes | what's unclear about that? | |
| 20:58:26 | mriedem | based on your reply to https://review.openstack.org/#/c/520663/9/nova/tests/unit/scheduler/client/test_report.py@1400 it means, in_tree with *any* node in the tree returns the entire tree | |
| 20:58:48 | jaypipes | ah I see | |
| 20:59:10 | mriedem | in my example, B and D are in the same tree because they share a common ancestor | |
| 20:59:18 | mriedem | but i wasn't sure about that | |
| 20:59:24 | mriedem | i mean on first reading of the api-ref | |
| 21:00:11 | efried | It doesn't say "subtree" or "below". I mean, we could add words to explain it more fully, including an example like the one in the comment. | |
| 21:00:24 | mriedem | http://lists.openstack.org/pipermail/openstack-dev/2017-December/125453.html | |
| 21:00:28 | mriedem | yeah that's what i asked for in ^ | |
| 21:01:11 | jaypipes | sorry, must have missed that | |
| 21:01:21 | mriedem | it's fine, it was 2 weeks before xmas | |
| 21:01:43 | efried | Think I was already out by then. Yeah, that's the excuse I'll use. | |
| 21:02:11 | mriedem | anyway, i think we're maybe in agreement about the spec? | |
| 21:02:15 | mriedem | before the tangent | |
| 21:02:48 | efried | mriedem: I'll take a crack at it. And a new spec for R. | |
| 21:03:36 | mriedem | thanks; i know it's not fun | |
| 21:04:02 | efried | mriedem: I'm doing it all for that shiny nickel you promised me back in the Fall. | |
| 21:04:12 | mriedem | ? | |
| 21:04:12 | mriedem | i promised a nickel | |
| 21:04:32 | efried | oh, totally. I have it in writing. | |
| 21:04:46 | mriedem | https://www.reddit.com/r/TheSimpsons/comments/1saamn/and_remember_a_shiny_new_donkey_for_whoever/ | |
| 21:04:53 | mriedem | if i did, it's because i ripped off the simpsons | |
| 21:05:37 | mriedem | ooo https://www.youtube.com/watch?v=0gGsKxMCM9o | |
| 21:07:57 | efried | mriedem: https://review.openstack.org/#/c/506370/ | |
| 21:08:01 | efried | note topic | |
| 21:08:17 | efried | I still need to find the eavesdrop where you offered it up, tho. | |
| 21:08:52 | mriedem | http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-21.log.html#t2017-09-21T16:39:19 | |
| 21:08:56 | efried | bwaHA http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-21.log.html#t2017-09-21T16:39:19 | |
| 21:08:59 | efried | yeah, what you said. | |
| 21:09:00 | mriedem | i win | |
| 21:09:13 | efried | Happy to concede that victory. I still get my nickel. | |
| 21:09:19 | mriedem | alright, fair enough | |
| 21:09:44 | efried | Do they have Euro nickels? | |
| 21:10:54 | efried | We've merged some Rocky specs at this point. Is the publish job broken again, or just slow? http://specs.openstack.org/openstack/nova-specs/specs/rocky/ | |
| 21:11:24 | mriedem | don't know | |
| 21:12:09 | efried | I don't see 540179 in the post queue. So... | |
| 21:13:49 | mriedem | i've got some 5 kronors from the czech republic.. | |
| 21:17:44 | mriedem | *koruna? | |
| 21:18:43 | openstackgerrit | Merged openstack/nova master: Remove unused tempest-dsvm-lxc-rc https://review.openstack.org/539244 | |
| 21:19:09 | openstackgerrit | Merged openstack/nova master: [placement] annotate loadapp as public interface https://review.openstack.org/526691 | |
| 21:22:17 | efried | mriedem: FYI that publish job is queued - filter by 32b00cc (which is apparently the merge commit hash for the spec patch). | |