<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-09-24 5:07 GMT+08:00 Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
Le 23/09/2016 18:41, Jay Pipes a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Stackers,<br>
<br>
In Newton, we had a major goal of having Nova sending inventory and allocation records from the nova-compute daemon to the new placement API service over HTTP (i.e. not RPC). I'm happy to say we achieved this goal. We had a stretch goal from the mid-cycle of implementing the custom resource class support. I'm sorry to say that we did not reach this goal, though Ironic did indeed get its part merged and we should be able to complete this work before the summit in Nova.<br>
<br>
Through the hard work of many folks [1] we were able to merge code that added a brand new REST API service (/placement) with endpoints for read/write operations against resource providers, inventories, allocations, and usage records. We were able to get patches merged that modified the resource tracker in the nova-compute to write the compute node's inventory and allocation records to the placement API in a fashion that avoided required action on the part of the operator to keep the nova-computes up and running.<br>
<br>
</blockquote>
<br></span>
Thanks Jay for giving us again your views.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For Ocata AND BEYOND, I'd here are a number of rough priorities and goals that we need to work on...<br>
<br>
1. Shared storage properly implemented<br>
<br>
To fulfill the original use case around accurate reporting of shared resources, we need to complete a few subtasks:<br>
<br>
a) complete the aggregates/ endpoints in the placement API so that resource providers can be associated with aggregates<br>
b) have the scheduler reporting client tracking more than just the resource provider for the compute node<br>
<br>
</blockquote>
<br></span>
I saw some patches about that. Let me know the changes so I could review them.<br>
For the client one, lemme know if you need some help.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Custom resource classes<br>
<br>
This actually isn't all that much work, but just needs some focus. We need the following done in this area:<br>
<br>
a) (very simple) REST API added to the placement API for GET/PUT resource class names<br>
b) modify the ResourceClass Enum field to be a StringField -- which is wire-compatible with Enum -- and add some code on each side of the client/server communication that caches the standard resource classes as constants that Nova and placement code can share<br>
c) modify the Ironic virt driver to pass the new node_class attribute on nodes into the resource tracker and have the resource tracker create resource provider records for each Ironic node with a single inventory record for each of those resource providers for the node class<br>
d) modify the resource tracker to track the allocation of instances to resource providers<br>
<br>
</blockquote>
<br></span>
So, first about that, sorry. I said during the midcycle that I could implement the above REST API but given I had an August time very short, I finally had no time for that. Now that we're in September, I can resume my implementation for a) and b).<br>
<br>
That said, we still have the spec to be approved by Ocata.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. Integration of Nova scheduler with Placement API<br>
<br>
We would like the Nova scheduler to be able to query the placement API for quantitative information in Ocata. So, code will need to be pushed that adds a call to the placement API for resource provider UUIDs that meet a given request for some amount of resources. This result will then be used to filter a request in the Nova scheduler for ComputeNode objects to satisfy the qualitative side of the request.<br>
<br>
</blockquote>
<br></span>
We tried to discuss about that during the midcycle, but it seemed we had some confusions about what could be calling the placement and where.<br>
>From my perspective, I was thinking the current scheduler would call out the placement API (or even directly using the Nova objects) during the HostManager call so that it would return less hosts for calling the filters. Thoughts?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. Progress on qualitative request components (traits)<br>
<br>
A number of things can be done in this area:<br>
<br>
a) get os-traits interface stable and include all catalogued standardized trait strings<br>
b) agree on schema in placement DB for storing and querying traits against resource providers<br>
<br>
</blockquote>
<br></span>
Given Ocata is a short cycle, and given the current specs are not yet fully discussed, I wonder if we would have time for having the above implemented ?<br>
I don't want to say we won't do that, just that it looks like a stretch goal for Ocata. At least, I think the discussion in the spec is a priority for Ocata, sure.</blockquote><div><br></div><div><br></div><div>Yea, very short cycle. I'm plan to update the spec. The update part is about hiding the standard traits validation behind the placement API. I and Yingxin work on the PoC, to show how was that looks like, hope we can done that in next week. Then I hope we have enough thing for people discussion. It is also good for people to measure what is worth to be done Ocata, and what isn't.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
5. Nested resource providers<br>
<br>
Things like SR-IOV PCI devices are actually resource providers that are embedded within another resource provider (the compute node itself). In order to tag things like SR-IOV PFs or VFs with a set of traits, we need to have discovery code run on the compute node that registers things like SR-IOV PF/VFs or SR-IOV FPGAs as nested resource providers.<br>
<br>
Some steps needed here:<br>
<br>
a) agreement on schema for placement DB for representing this nesting relationship<br>
b) write the discovery code in nova-compute for adding these resource providers to the placement API when found<br>
<br>
</blockquote>
<br></span>
Again, that looks like a stretch goal to me, given how small we already discussed about that yet. But sure, Ocata would be fine for discussing first.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyway, in conclusion, we've got a ton of work to do and I'm going to spend time before the summit trying to get good agreement on direction and proposed implementation for a number of the items listed above. Hopefully by mid-October we'll have a good idea of assignees for various work and what is going to be realistic to complete in Ocata.<br>
<br>
Best,<br>
-jay<br>
<br>
[1] I'd like to personally thank Chris Dent, Dan Smith, Sean Dague, Ed Leafe, Sylvain Bauza, Andrew Laski, Alex Xu and Matt Riedemann for tolerating my sometimes lengthy absences and for pushing through communication breakdowns resulting from my inability to adequately express my ideas or document agreed solutions.<br>
<br>
</blockquote>
<br></span>
Heh, thanks buddy. No worries about your absences, we had an awesome Dan for helping us :-)<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote>
<br>
<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>