In https://review.openstack.org/#/c/496212 I've started the process
of moving some of the generally useful microversion-related
functions out of the placement service and into the microversion-parse
library. This will help make the library more useful (see the
README.rst in the review for examples).
I have, however, thus far left out some of the serious microversion meat
that is still in use in placement:
* decorator for handling mulitple callables of the same name based
on microversion
* utility method to raise a status code response based microversion
match (things like: respond with a 404 if the microversion is less
than (1, 1))
* middleware that extracts the microversion from headers (using
microversion-parse), sticks it in the environment, and sends
microversion headers on every response
The reason these are not included is because all of them use webob,
primarily in two different ways:
* raising webob exceptions within a webob.dec.wsgify context,
causing well formed error responses
* using a json formatter to structure error responses according to
api guidelines
I'm hesitant to add these because they would introduce a dependency
on webob and enforce some behaviors in the projects that use them.
The options seem to be:
* Don't worry, nobody but nova and placement is using
microversion-parse and nobody else has plans to do so.
* Don't worry about it, everyone loves webob, include it.
* I _think_ I can keep the use of webob contained in a way that makes
sure it doesn't impact the rest of the WSGI stack (less sure
about the error formatter).
* With some more effort I could do raw WSGI handling, leaving out
the use of webob stuff.
I'm kind of inclined towards the last option, but I'm not sure it is
worth it if there aren't any interested parties.
To be clear, if I move the missing parts mentioned above into
microversion-parse, what it could then become is a generic
microversion handling library, including WSGI middleware, satisfying
most common microversion needs. If I don't move them, it's still
useful, but projects would still need to write their own middleware.
Given the diversity of stacks we have in use, that might be how it
would have to work anyway.
--
Chris Dent (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
