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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
