<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">Le 17/06/2016 12:55, Chris Dent a
écrit :<br>
</div>
<blockquote
cite="mid:alpine.OSX.2.20.1606171102370.41543@shine.local"
type="cite">
<br>
tl;dr: Have a look at <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/329386/">https://review.openstack.org/#/c/329386/</a> to
<br>
help move some placement API decisions along.
<br>
<br>
Not really that long, do read:
<br>
<br>
As part of the generic resource pools spec[1] a new, independent
of
<br>
the rest of nova, API is being developed called the "Placement
API".
<br>
The API will initially allow for the management of resource
<br>
providers. There are entities which provide classes of
resources[2]
<br>
such as VPCU, DISK_GB, IPV4_ADDRESS.
<br>
<br>
At the Bristol mid-cycle it was decided that the placement api
should
<br>
be developed in such a way that it will be easy™ to lift it into
its
<br>
own project at some date in the future. In that future the
placement
<br>
api will be able to help "place" lots of things, not just
instances.
<br>
<br>
It was also decided that this lift and shift afforded an
opportunity
<br>
to explore ways of hosting and testing an HTTP API that are
different
<br>
from the modes originated in nova. Not for the sake of being
different
<br>
but because the nova way has issues including inscrutability.
<br>
<br>
I started a WIP a few months back to start exploring this new
<br>
API. Recently it's been chunkified into smaller reviews[3].
<br>
<br>
For testing I've been using gabbi[4] because it does good TDD for
<br>
this kind of thing and also does a great job of satisfying the
<br>
declarative proposal in the api-wg testing guideline[5]. I hope
this
<br>
is not controversial.
<br>
<br>
Where the controversy enters the picture has been in my choice of
<br>
how to structure the code that hosts the API. It's been clear from
<br>
the start that we want to use as little of the nova infrastructure
<br>
as possible. What's undecided is which of two strategies should be
<br>
followed. In broad strokes those strategies are:
<br>
<br>
* Go all in on a common framework, probably Flask[6], and use it
in its own
<br>
specific way.
<br>
* Don't use a framework at all. WSGI has never needed one. Just
<br>
compose some WSGI-apps, middleware and utilities and let them do
<br>
their work.
<br>
<br>
For now I've chosen the latter because it provides a level of
<br>
simplicity, inspectability, testability and control that I think
is
<br>
lost when using a framework. I know for many people in the
OpenStack
<br>
community not using a framework goes against the grain, but have a
look
<br>
at the code[7], it's pretty simple Python.
<br>
<br>
</blockquote>
<br>
+1000 yes to that. Now the devil could be in the details, in
particular how we implement the WSGI server, the corresponding WSGI
app and the associated routing, and that's exactly the problem
below.<br>
That said, I'm not expert in that domain, just had a bit of
experience in that in the past. So, feel free to level my opinion by
how you want :-)<br>
<br>
<br>
<blockquote
cite="mid:alpine.OSX.2.20.1606171102370.41543@shine.local"
type="cite">One of the dependencies in this model is selector[8].
The discussion
<br>
around the review of getting it into global-requirements[9] is
what
<br>
has prompted this email. Discussion there has suggested that the
<br>
resistance to the second strategy may be significant enough that
we
<br>
should go with the first one. I think we need to decide that
sooner
<br>
than later so this email is an invitation to join in the
discussion,
<br>
either here or on the review of selector[9] or the initial API[3].
<br>
<br>
</blockquote>
<br>
I certainly understand the concerns of adding yet another library.
To be honest, I tend to even agree with the statement that we could
possibly use Routes without explicitly use nova.wsgi, right ?<br>
<br>
In the review, you explain why you don't trust Routes and I respect
that. That said, are those issues logged as real problems for our
API consumers, which are mostly client libraries that we own and
other projects we know, like Horizon ?<br>
<br>
If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?<br>
<br>
-Sylvain<br>
<br>
<blockquote
cite="mid:alpine.OSX.2.20.1606171102370.41543@shine.local"
type="cite">From my standpoint, as the person writing the initial
code, it would be
<br>
great to get this resolved soon. If we need to make a change,
making
<br>
a simple WSGI app into a working Flask app is something other than
<br>
trivial, but I value us having consensus over how to do this over
my
<br>
feelings about Flask and frameworks.
<br>
<br>
To be clear: I don't like Flask, at all, it is too magic and too
<br>
obscuring of the way HTTP works. You have to commit to it all the
way
<br>
to get the most benefit from it and when you do that a lot of
inspectability
<br>
is lost behind implicit magic and you are stuck with it
henceforth.
<br>
Implicit magic is absolutely horrible for long term maintenance,
<br>
especially in communities where many of the contributors come and
go.
<br>
The code I've written in the WIP tries to break with many of code
trends
<br>
that require readers to guess.
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html">http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html</a><br>
[2]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/resource-classes.html">http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/resource-classes.html</a><br>
[3] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/329149/">https://review.openstack.org/#/c/329149/</a> and its descendants
[4] <a class="moz-txt-link-freetext" href="https://gabbi.readthedocs.io/">https://gabbi.readthedocs.io/</a>
<br>
[5]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/api-wg/guidelines/testing.html#proposals">http://specs.openstack.org/openstack/api-wg/guidelines/testing.html#proposals</a><br>
[6] <a class="moz-txt-link-freetext" href="http://flask.pocoo.org/">http://flask.pocoo.org/</a>
<br>
[7]
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/329151/10/nova/api/openstack/placement/handlers/resource_provider.py">https://review.openstack.org/#/c/329151/10/nova/api/openstack/placement/handlers/resource_provider.py</a><br>
[8] <a class="moz-txt-link-freetext" href="https://pypi.python.org/pypi/selector">https://pypi.python.org/pypi/selector</a>
<br>
[9] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/329386/">https://review.openstack.org/#/c/329386/</a>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>