[openstack-dev] [nova] Latest news on placement API and Ocata rough goals

Alex Xu soulxu at gmail.com
Sat Sep 24 02:28:48 UTC 2016


2016-09-24 5:07 GMT+08:00 Sylvain Bauza <sbauza at redhat.com>:

>
>
> Le 23/09/2016 18:41, Jay Pipes a écrit :
>
>> Hi Stackers,
>>
>> 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.
>>
>> 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.
>>
>>
> Thanks Jay for giving us again your views.
>
> For Ocata AND BEYOND, I'd here are a number of rough priorities and goals
>> that we need to work on...
>>
>> 1. Shared storage properly implemented
>>
>> To fulfill the original use case around accurate reporting of shared
>> resources, we need to complete a few subtasks:
>>
>> a) complete the aggregates/ endpoints in the placement API so that
>> resource providers can be associated with aggregates
>> b) have the scheduler reporting client tracking more than just the
>> resource provider for the compute node
>>
>>
> I saw some patches about that. Let me know the changes so I could review
> them.
> For the client one, lemme know if you need some help.
>
> 2. Custom resource classes
>>
>> This actually isn't all that much work, but just needs some focus. We
>> need the following done in this area:
>>
>> a) (very simple) REST API added to the placement API for GET/PUT resource
>> class names
>> 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
>> 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
>> d) modify the resource tracker to track the allocation of instances to
>> resource providers
>>
>>
> 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).
>
> That said, we still have the spec to be approved by Ocata.
>
>
> 3. Integration of Nova scheduler with Placement API
>>
>> 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.
>>
>>
> 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.
> 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?
>
> 4. Progress on qualitative request components (traits)
>>
>> A number of things can be done in this area:
>>
>> a) get os-traits interface stable and include all catalogued standardized
>> trait strings
>> b) agree on schema in placement DB for storing and querying traits
>> against resource providers
>>
>>
> 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 ?
> 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.



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.


>
>
> 5. Nested resource providers
>>
>> 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.
>>
>> Some steps needed here:
>>
>> a) agreement on schema for placement DB for representing this nesting
>> relationship
>> b) write the discovery code in nova-compute for adding these resource
>> providers to the placement API when found
>>
>>
> 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.
>
> 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.
>>
>> Best,
>> -jay
>>
>> [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.
>>
>>
> Heh, thanks buddy. No worries about your absences, we had an awesome Dan
> for helping us :-)
>
>
> __________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160924/c100ee9d/attachment.html>


More information about the OpenStack-dev mailing list