Open Stack

I've been reviewing my notes from the mid-cycle and discussions
leading up to it and realized I have a few unresolved or open topics
that I hope discussion here can help resolve:

# fairly straightforward things

* At what stage in the game (of the placement api) do we need to
   implement oslo_policy handling and enforcement? Right now the auth
   model is simply all-admin-role-all-the-time.

* There was some discussion of adding a configuration setting (e.g.
   'placement_connection') that if not None (the default) would be
   used as the connection for the placement database. If None, the
   API database would be used. I can't recall if we said 'yea' or
   'nay' to this idea. The current code uses the api database and its
   config.

# less straightforward and further out things

There was some discussion that conflicted with reality a bit and I
think we need to resolve before too long, but shouldn't impact the
newton-based changes:

We bounced around two different HTTP resources for returning one or
several resource providers in response to a launch request:

* POST /allocations

   returns a representation of the one target for this launch
   request, already claimed

* GET /resource_providers

   returns a list of candidate targets for a launch request, similar
   to what the existing select_destinations RPC call can do

The immediate problem here is that something else is already using
GET /resource_providers:

    http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html#get-resource-providers

Whatever the URI, it's not clear that GET would be correct here:

* We'll probably want to send a body so GET is not ideal.

* We could pass a reference to a persisted "request spec" as a query
   string item, thus maintaining a GET, but that seems to go against
   the grain of "give a thing the info it needs to get stuff done" that
   is elsewhere in the system.

   I'd personally be pretty okay with launch-info-by-reference mode as
   it allows the placement API to be in charge of request what version
   of a launch request it wants rather than its clients needing to know
   what version the placement API might accept.

It's pretty clear that were going to need at least an interim and
maybe permanent endpoint that returns a list of candidate target
resource providers. This is because, at least initially, the
placement engine will not be able to resolve all requirements down
to the one single result and additional filtering may be required in
the caller.

The question is: Will that need for additional filtering always be
present and if so do we:

* consider that a bad thing that we should strive to fix by
   expanding the powers and size of the placement engine
* consider that a good thing that allows the placement engine to be
   relatively simple and keeps edge-case behaviors being handled
   elsewhere

If the latter, then we'll have to consider how an allocation/claim
in a list of potential allocations can be essentially reserved,
verified, or rejected.

As an example of expanding the powers, there is the
ResourceProviderTags concept, described in:

     https://review.openstack.org/#/c/345138/

This will expand the data model of resource providers and the surface
area of the HTTP API. This may very well be entirely warranted, but
there might be other options if we assuming that returning a list is
"normal".

Sorry if this is unclear. I'm rather jet-lagged. Ask questions if
you have them. Thanks.

-- 
Chris Dent               ┬─┬ノ( º _ ºノ)         http://anticdent.org/
freenode: cdent                                         tw: @anticdent