Open Stack

Le 04/06/2016 16:37, Dan Smith a écrit :
>> 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).
>

Right, I take this upcall as the main problem we could have in a cells 
v2 world.
Using a REST API call for providing the resource inventories sounds good 
to me.


>> * 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.

I think there are two very different points :

#1 Nova and other projects like Neutron or Cinder can provide their own 
inventories, so we need some kind of REST API for that. Good to me, +2.

#2 For the moment, only Nova wants to ask the scheduler to give it a 
destination, not Cinder or Neutron. Sure, we want to ask the scheduler 
to give us a destination possibly having a cross-project affinity, but 
that's still a compute node that the scheduler gives back to the nova 
conductor. By that, I'm really trying to explain that providing a REST 
API for selecting a destination really needs to be discussed more than 
by e-mails and also needs to see how the current request and the 
returned destination (a tuple now) can be interfaced for more than just 
nova. I don't think it's what we want to have *now*.


>> * 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.

++

>> * 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...
>


Agreed, that's not because we don't have a REST API indirection yet in 
Nova that we can't be having it next.

>> * 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.

Yes, +1000 to what you say. Nova is *at the moment* the only consumer of 
that placement API, we don't want to resurrect a project that was 
defunct for good reasons by working on that epic story.

-Sylvain

> --Dan
>
> __________________________________________________________________________
> 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