Open Stack

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

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

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

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

--Dan