| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-12 | |||
| 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 | |
| 22:08:03 | mriedem | because this is fine http://logs.openstack.org/63/543263/2/check/legacy-tempest-dsvm-neutron-nova-next-full/1c23f03/logs/devstack-gate-post_test_hook.txt.gz | |
| 22:08:37 | mriedem | i bet it's the set -e | |
| 22:09:37 | dansmith | if you set -e in the post hook script then yeah | |
| 22:09:58 | mriedem | but i'm not sure why it'd be blowing up when archive_deleted_rows runs | |
| 22:10:02 | mriedem | since it doesn't look like that is failing | |
| 22:10:56 | dansmith | it returns 1 until you don't need to run it again right? | |
| 22:11:54 | mriedem | it runs the loop up to 30 times as long as the CLI returns 1 | |
| 22:11:59 | mriedem | until it returns 0 for all done | |
| 22:12:06 | dansmith | right | |
| 22:12:10 | dansmith | but set -e will break that right? | |
| 22:12:30 | mriedem | yeah i forgot how strict that was | |
| 22:12:36 | mriedem | need to capture the $? differently | |
| 22:12:51 | mriedem | or, just move the set -e to later | |
| 22:12:55 | dansmith | well, unset -e during that loop or put it somewhere else or run it in a subshell | |
| 22:12:57 | dansmith | yeah | |
| 22:13:14 | mriedem | yeah i had this in a separate file earlier but couldn't figure out why it was failng, now it's pretty obvious | |