Open Stack

tl;dr: Have a look at https://review.openstack.org/#/c/329386/ to
help move some placement API decisions along.

Not really that long, do read:

As part of the generic resource pools spec[1] a new, independent of
the rest of nova, API is being developed called the "Placement API".
The API will initially allow for the management of resource
providers. There are entities which provide classes of resources[2]
such as VPCU, DISK_GB, IPV4_ADDRESS.

At the Bristol mid-cycle it was decided that the placement api should
be developed in such a way that it will be easy™ to lift it into its
own project at some date in the future. In that future the placement
api will be able to help "place" lots of things, not just instances.

It was also decided that this lift and shift afforded an opportunity
to explore ways of hosting and testing an HTTP API that are different
from the modes originated in nova. Not for the sake of being different
but because the nova way has issues including inscrutability.

I started a WIP a few months back to start exploring this new
API. Recently it's been chunkified into smaller reviews[3].

For testing I've been using gabbi[4] because it does good TDD for
this kind of thing and also does a great job of satisfying the
declarative proposal in the api-wg testing guideline[5]. I hope this
is not controversial.

Where the controversy enters the picture has been in my choice of
how to structure the code that hosts the API. It's been clear from
the start that we want to use as little of the nova infrastructure
as possible. What's undecided is which of two strategies should be
followed. In broad strokes those strategies are:

* Go all in on a common framework, probably Flask[6], and use it in its own
   specific way.
* Don't use a framework at all. WSGI has never needed one. Just
   compose some WSGI-apps, middleware and utilities and let them do
   their work.

For now I've chosen the latter because it provides a level of
simplicity, inspectability, testability and control that I think is
lost when using a framework. I know for many people in the OpenStack
community not using a framework goes against the grain, but have a look
at the code[7], it's pretty simple Python.

One of the dependencies in this model is selector[8]. The discussion
around the review of getting it into global-requirements[9] is what
has prompted this email. Discussion there has suggested that the
resistance to the second strategy may be significant enough that we
should go with the first one. I think we need to decide that sooner
than later so this email is an invitation to join in the discussion,
either here or on the review of selector[9] or the initial API[3].

>From my standpoint, as the person writing the initial code, it would be
great to get this resolved soon. If we need to make a change, making
a simple WSGI app into a working Flask app is something other than
trivial, but I value us having consensus over how to do this over my
feelings about Flask and frameworks.

To be clear: I don't like Flask, at all, it is too magic and too
obscuring of the way HTTP works. You have to commit to it all the way
to get the most benefit from it and when you do that a lot of inspectability
is lost behind implicit magic and you are stuck with it henceforth.
Implicit magic is absolutely horrible for long term maintenance,
especially in communities where many of the contributors come and go.
The code I've written in the WIP tries to break with many of code trends
that require readers to guess.

[1] http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html
[2] http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/resource-classes.html
[3] https://review.openstack.org/#/c/329149/ and its descendants 
[4] https://gabbi.readthedocs.io/
[5] http://specs.openstack.org/openstack/api-wg/guidelines/testing.html#proposals
[6] http://flask.pocoo.org/
[7] https://review.openstack.org/#/c/329151/10/nova/api/openstack/placement/handlers/resource_provider.py
[8] https://pypi.python.org/pypi/selector
[9] https://review.openstack.org/#/c/329386/

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