Open Stack

(Warning, there might be crazy ideas ahead, mostly sending this out
to engender some discussion and if these ideas are indeed crazy use
their debunking as ways to strengthen and clarifying existing plans.)

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.

Until now the various proposed patches related to resource providers,
generic resource pools, inventories and allocations have been calling
methods on versioned objects to do persistence direct to the database.

If we're going to move to an HTTP-only API I wonder if that gives us
some opportunities to minimize complexity in the longer term
architecture:

* If we have many placement API servers talking to the same logical
   datastore
* And if we don't need a conductor
* And we have schematized representations in the API

Then might it be possible that we don't need oslo versioned objects nor
RPC and we can separate persistence from data structure?

If desired we could still use OVO to version the structure of, for
example, inventory information, but rather than telling an Inventory (or
InventoryList) to save itself, the API would save the information. The
complexity seems to enter picture when we try to make this stuff
remotable and self-persistable. If there's no conductor we don't need
really need that, do we? Or do we? If so, why?

Then:

* 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".
* If API needs to be versioned then it can version the external
   representations that it uses.

What I'm concerned about is mainly two things:

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

* 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.
   That's a tedious dependency. Using versioned objects on both side
   would allow us to co-evolve and make it relatively easy in some
   ways, but that's bad in some ways. I think we're better off making it
   hard to change the on-the-wire representation and keep the
   expectations of the placement API strict and as static as possible.
   Since we don't have to represent fungible things like
   an-extremely-verbose-description-of-a-computer-and-all-extra-bits,
   only Inventory of some type, Allocation of some of that Inventory,
   and a thing which has some inventory we should try to get away
   with it, for the sake of simplicity[1].

I'm talking from a position of ignorance here, so I may be talking
completely BS, but I wanted to get this stuff out there so it was in
the shared mental mix.

[1] What I'm suggesting here is that strictness of representation is
a useful constraint for the development of the system.

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