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