Open Stack

Thanks for the response, it's very useful to (to me at least) to
hash this stuff out in writing. More hashing and crazy talk below.

On Sat, 4 Jun 2016, 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.

Sure, but the change has been in the ordering and that has impact on
the several pieces involved.

>> * 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, I think this gets to the center of some of the questions and
leads to some more: If the long term plan is inventory management
over HTTP and some major portion of filter is over SQL what happens
with those filters that are more dynamic (are metrics a good example
of such a thing?)?

The boundaries between stuff start getting weird.

If we can come up with a plan whereby we don't need the queue then a
lot of the things we _could_ do turn into premature optimizations.
But of course if we must have the queue, then that's not the case.

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

For clarity of understanding and completeness of picture can you explain
why this is so and also why you are so sure that it is so[1]?

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

I come from the school of thought that thinks that self-persisting
objects is backwards. There should be objects, which can be
persisted by other things and the interfaces should be kept
separate. In large part that's just a matter of taste (because in
the end the same stuff has to happen) or preference, so probably not
really worth talking about, except in the context of one of several
options for reducing complexity.

Strategies for that reduction in complexity is what I'm hoping to
extract from this thread. We have a lot of patterns in Nova that are
default solutions and tend to be repeated elsewhere because Nova's
had success with them. What's often forgotten is that some of those
solutions are fixes for problems that won't exist in new tools because
of different initial approaches.

So, for example, if there is a chance we can figure out up front how
to make the placement service be "data only" (in the sense that you
describe above) it becomes a lot easier to upgrade when there are
new releases.

Or, if we realize that it must have access to more dynamic information,
we could consider other solutions than persistent state via call-based
RPC over messaging over OVO as solutions. For example, just picking out
of the sky here, pub/sub events with tiny datasets.

Or if that is impossible, at least we know we thought about it.

Thanks again, this is all about putting some real context on the
bones we toss around.

[1] There's a school of API design that says versioning APIs is an
anti-pattern. You shouldn't version, but if you must, you should
version representations, not the API wholesale. (As in this is
version 2.1 of a "server" resource, in JSON.)

-- 
Chris Dent               (╯°□°)╯︵┻━┻            http://anticdent.org/
freenode: cdent                                         tw: @anticdent