Open Stack

On 06/04/2016 10:37 AM, Dan Smith wrote:
>> There was a conversation earlier this week in which, if I understood
>> things correctly, one of the possible outcomes was that it might make
>> sense for the new placement service (which will perform the function
>> currently provided by the scheduler in Nova) to only get used over its
>> REST API, as this will ease its extraction to a standalone service.
>
> FWIW, I think that has been the long term expectation for a while.
> Eventually that service is separate, which means no RPC to/from Nova
> itself. The thing that came up last week was more a timing issue of
> whether we go straight to that in newton or stop at an intermediate
> stage where we're still using RPC. Because of the cells thing, I was
> hoping to be able to go straight to HTTP, which would be slightly nicer
> than what is actually an upcall from the cell to the API (even though
> we're still pretty flat).

Agreed, and the above matches my thinking from the status update email I 
sent earlier today to the openstack-dev@ ML. I believe the only 
difference between your thoughts on this and my own are the 
implementation details of how those placement HTTP API calls would be 
made. I believe you want to see those calls done in the 
nova.objects.Inventory[List] object whereas I was hoping to have the 
resource tracker instead call a placement_client.update_inventory() call 
which would be responsible for talking to the placement REST API 
endpoint and the placement REST API endpoint would save inventory state 
to the Nova API database via calls to a 
nova.objects.ResourceProvider.update_inventory() method.

>> * The way to scale is to add more placement API servers and more
>>    nodes in the galera (or whatever) cluster. The API servers just
>>    talk to the persistence layer themselves. There are no tasks to
>>    "conduct".
>
> I'm not sure that we'll want to consider this purely a data service. The
> new resource filter approach is mostly a data operation, but it's not
> complete -- it doesn't actually select a resource. For that we still
> need to run some of the more complicated scheduler filters. I'm not sure
> that completely dispensing with the queue (or queuing of some sort) and
> doing all the decisions in the API worker while we hold the HTTP client
> waiting is the right approach. I'd have to think about it more.

Yeah, we can talk about this more in the future but I don't believe we 
need to complicate the current proposal any further than it already is.

>> * If API needs to be versioned then it can version the external
>>    representations that it uses.
>
> It certainly needs to be versioned, and certainly that versioned
> external representation should be decoupled from the actual persistence.

Agreed.

>> * Nova-side versioned objects that are making http calls in
>>    themselves. For example, an Inventory object that knows how to
>>    save itself to the placement API over HTTP. Argh. No. Magical
>>    self-persisting objects are already messy enough. Adding a second
>>    medium over which persistence can happen is dire. Let's do
>>    something else please.
>
> Um, why? What's the difference between a remotable object that uses
> rabbit and RPC to ask a remote service to persist a thing, versus a
> remotable object that uses HTTP to do it? It seems perfectly fine to me
> to have the object be our internal interface, and the implementation
> behind it does whatever we want it to do at a given point in time (i.e.
> RPC to the scheduler or HTTP to the placement service). The
> indirection_api in ovo is pluggable for a reason...
>
>> * A possible outcome here is that we're going to have objects in Nova
>>    and objects in Placement that people will expect to co-evolve.
>
> I don't think so. I think the objects in Nova will mirror the external
> representation of the placement API, much like the nova client tracks
> evolution in nova's external API.

++

 > As placement tries to expand its scope
> it is likely to need to evolve its internal data structures like
> anything else.

Agreed.

Best,
-jay