<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-07-07 19:44 GMT+08:00 Chris Dent <span dir="ltr"><<a href="mailto:cdent+os@anticdent.org" target="_blank">cdent+os@anticdent.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
After 40 days in the desert I've returned with placement update 27.<br>
<br>
Unfortunately, as far as I can tell, no one did any updates while I<br>
was gone so I don't have anything to crib from to have the full<br>
story on what's going on. I suspect I will miss some relevant<br>
reviews when making this list. If I have, please let me know.<br>
Otherwise, let's begin:<br>
<br>
# What Matters Most<br>
<br>
Claims in the scheduler remains the key feature we'd like to get in<br>
before feature freeze. After some hiccups on how to do it, making<br>
requests of the new /allocation_candidates (of which more, below) is<br>
the way to go. Changes for that are starting at<br>
<br>
<a href="https://review.openstack.org/#/c/476631/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/476631/</a><br>
<br>
# What's Changed<br>
<br>
As mentioned, there's now a new URL in the placement API:<br>
GET /allocation_candidates. It has a similar interface to GET<br>
/resource_providers (in that you can filter the results by the kind<br>
of resources required) but the information is formatted as a<br>
two-tuple of lists of allocation requests and a dictionary of<br>
resource provider information. The latter will provide the initial<br>
list of available resource providers and augment the process of<br>
filtering and weighing those providers. The former provides a<br>
collection of correctly formed JSON bodies that can be sent in a PUT<br>
to /allocations/{consumer_uuid} when making a claim.<br>
<br>
I'm still a bit confused about where the concept of "alternatives"<br>
that are going to be passed to the cell conductors fits into this,<br>
but I guess that will become more clear soon.<br>
<br>
It also seems like this model creates a pretty strong conceptual<br>
coupling between a thing which behaves like a nova-scheduler<br>
(request, process, then claim resources). As placement becomes<br>
useful to other services it will be important to revisit some of<br>
these decisions and make sure the HTTP API is not imposing too many<br>
behaviuor requirements on the client side (otherwise why bother<br>
having an HTTP API?). But that's for later. Right now we're on a<br>
tight schedule trying to make sure that claims get in in Ocata.<br>
<br>
Because there's a bit of a dependency hierarchy with the various<br>
threads of work going on in placement, the work on claims may punt<br>
traits and/or nested resource providers further down the timeline.<br>
Work continues on all three concurrently.<br>
<br>
Another change is that allocations now include project id and user<br>
id information and usages by those id can be retrieved.<br>
<br>
# Help Wanted<br>
<br>
Areas where volunteers are needed.<br>
<br>
* General attention to bugs tagged placement:<br>
<a href="https://bugs.launchpad.net/nova/+bugs?field.tag=placement" rel="noreferrer" target="_blank">https://bugs.launchpad.net/no<wbr>va/+bugs?field.tag=placement</a><br>
<br>
# Main Themes<br>
<br>
## Claims in the Scheduler<br>
<br>
As described above there's been a change in direction. That probably<br>
means some or all of the code now at<br>
<br>
<a href="https://review.openstack.org/#/q/status:open+topic:bp/placement-claims" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/status:open+topic:bp/placem<wbr>ent-claims</a><br>
<br>
can be abandoned in favor of the work at<br>
<br>
<a href="https://review.openstack.org/#/q/topic:bp/placement-allocation-requests+status:open" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/topic:bp/placement-allocati<wbr>on-requests+status:open</a><br>
<br>
The main starting point for that is<br>
<br>
<a href="https://review.openstack.org/#/c/476631/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/476631/</a><br>
<br>
## Traits<br>
<br>
The concept of traits now exists in the placement service, but<br>
filtering resource providers on traits is in flux. With the advent<br>
of /allocation_candidates as the primary scheduling interface, that<br>
needs to support traits. Work for that is in a stack starting at<br>
<br>
<a href="https://review.openstack.org/#/c/478464/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/478464/</a><br>
<br>
It's not yet clear if we'll want to support traits at both<br>
/allocation_candidates and /resource_providers. I think we should,<br>
but the immediate need is on /allocation_candidates.<br></blockquote><div><br></div><div>For traits support in /allocation_candidates, I started some patches:</div><div><a href="https://review.openstack.org/478464">https://review.openstack.org/478464</a><br></div><div><a href="https://review.openstack.org/479766">https://review.openstack.org/479766</a><br></div><div><a href="https://review.openstack.org/479776">https://review.openstack.org/479776</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
There's some proposed code to get the latter started:<br>
<br>
<a href="https://review.openstack.org/#/c/474602/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/474602/</a> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
## Shared Resource Providers<br>
<br>
Support for shared resource providers is "built in" to the<br>
/allocation_candidates concept and one of the drivers for having it.<br>
<br>
## Nested Resource Providers<br>
<br>
Work continues on nested resource providers.<br>
<br>
<a href="https://review.openstack.org/#/q/status:open+topic:bp/nested-resource-providers" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/status:open+topic:bp/nested<wbr>-resource-providers</a><br>
<br>
The need with these is simply more review, but they are behind<br>
claims in priority.<br>
<br>
## Docs<br>
<br>
Lots of placement-related api docs have merged or are in progress:<br>
<br>
<a href="https://review.openstack.org/#/q/status:open+topic:cd/placement-api-ref" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/status:open+topic:cd/placem<wbr>ent-api-ref</a><br>
<br>
Shortly there will be a real publishing job:<br>
<br>
<a href="https://review.openstack.org/#/c/480991/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/480991/</a><br>
<br>
and the tooling which tests that new handlers are documented<br>
will be turned on:<br>
<br>
<a href="https://review.openstack.org/#/c/480924/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/480924/</a><br>
<br>
Some changes have been proposed to document the scheduler's<br>
workflow, including visual aids, starting at:<br>
<br>
<a href="https://review.openstack.org/#/c/475810/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/475810/</a><br>
<br>
# Other Code/Specs<br>
<br>
* <a href="https://review.openstack.org/#/c/472378/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/472378/</a><br>
A proposed fix to using multiple config locations with the<br>
placement wsgi app. There's some active discussion on whether the<br>
solution in mind is the right solution, or even whether the bug is<br>
a bug (it is!).<br>
<br>
* <a href="https://review.openstack.org/#/c/470578/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/470578/</a><br>
Add functional test for local delete allocations<br>
<br>
* <a href="https://review.openstack.org/#/c/427200/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/427200/</a><br>
Add a status check for legacy filters in nova-status.<br>
<br>
* <a href="https://review.openstack.org/#/c/469048/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/469048/</a><br>
Provide more information about installing placement<br>
<br>
* <a href="https://review.openstack.org/#/c/468928/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/468928/</a><br>
Disambiguate resource provider conflict message<br>
<br>
* <a href="https://review.openstack.org/#/c/468797/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/468797/</a><br>
Spec for requesting traits in flavors<br>
<br>
* <a href="https://review.openstack.org/#/c/480379/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/480379/</a><br>
ensure shared RP maps with correct root RP<br>
(Some discussion on this one what the goal is and whether the<br>
approach is the right one.)<br>
<br>
# End<br>
<br>
That's all I've got this week, next week I should be a bit more<br>
caught up and aware of any bits I've missed. No prize this week, but<br>
maybe next week.<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Chris Dent ┬──┬◡ﾉ(° -°ﾉ) <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
freenode: cdent tw: @anticdent</font></span><br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>