| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-12 | |||
| 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). | |
| 21:34:36 | efried | mriedem: Just confirming: we don't branch nova-specs? So I don't need to propose this edit "back" to queens? | |
| 21:34:54 | efried | ...other than by virtue of it being in the .../queens/... subdirectory | |
| 21:35:47 | mriedem | efried: correct | |
| 21:35:55 | efried | ack | |
| 21:36:08 | mriedem | much like the american constitution, it's a living document | |
| 21:48:15 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 21:48:15 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Move resource provider objects into placement hierarchy https://review.openstack.org/540049 | |
| 21:48:16 | openstackgerrit | Chris Dent proposed openstack/nova master: Isolate config parse_args for placement https://review.openstack.org/543495 | |
| 21:48:16 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Isolate placement database config https://review.openstack.org/541435 | |
| 21:53:15 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Re-propose use Neutron's new port binding API https://review.openstack.org/543578 | |
| 21:58:27 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Handle volume-backed instances in IsolatedHostsFilter https://review.openstack.org/543635 | |
| 21:58:27 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Add regression test for BFV+IsolatedHostsFilter failure https://review.openstack.org/543634 | |
| 21:58:28 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Fix docs for IsolatedHostsFilter https://review.openstack.org/543636 | |
| 22:06:30 | mriedem | i think archive_deleted_rows might be broken | |
| 22:07:01 | dansmith | mriedem: I think I might be volunteering to work on archive and purge this cycle | |
| 22:07:30 | mriedem | there is something weird going on here http://logs.openstack.org/10/538510/7/check/legacy-tempest-dsvm-neutron-nova-next-full/b808474/job-output.txt.gz#_2018-02-09_20_15_11_712319 | |
| 22:07:59 | mriedem | although maybe it's just my patch | |