Earlier  
Posted Nick Remark
#openstack-nova - 2018-02-12
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
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

Earlier   Later