<div dir="ltr"><div>It's nice to hear about HTTP API.</div><div>I'm quite new in nova and openstack and don't grasp all that rpc</div><div>things yet and can miss something but anyway I have several thoughts about API.</div><div><br></div><div>Boring standpoint. First to choose some technology I think we can look at how widely</div><div>it's adopted and how many people at local community (openstack)</div><div>use it. I checked out several openstack projects (keystone, swift,</div><div>cinder) and it's Paste I think.</div><div>IMHO selector is too young in terms of version (0.1) and too old in</div><div>terms of updates (3 years ago).</div><div><br></div><div>Idea. I absolutely agree with you about flask and his magic.</div><div>And if we want to start totally new it can be werkzeug or webob.</div><div>And if we go further I wonder why in nova we don't use </div><div>asynchronous approach. All these API calls which just transfer</div><div>from one point to another are perfect candidates.</div><div><br></div><div>About API. It would be great for new service to have auto schema</div><div>description/validation and may be some optional stuff like duplicate</div><div>protection, call signature.</div><div><br></div><div>About gabbi. Could you please give several procs on declarative style</div><div>in yaml vs declarative style in python?</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 17, 2016 at 1:55 PM, Chris Dent <span dir="ltr"><<a href="mailto:cdent+os@anticdent.org" target="_blank">cdent+os@anticdent.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
tl;dr: Have a look at <a href="https://review.openstack.org/#/c/329386/" rel="noreferrer" target="_blank">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>
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>
>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 href="http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html</a><br>
[2] <a href="http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/resource-classes.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/resource-classes.html</a><br>
[3] <a href="https://review.openstack.org/#/c/329149/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/329149/</a> and its descendants [4] <a href="https://gabbi.readthedocs.io/" rel="noreferrer" target="_blank">https://gabbi.readthedocs.io/</a><br>
[5] <a href="http://specs.openstack.org/openstack/api-wg/guidelines/testing.html#proposals" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/api-wg/guidelines/testing.html#proposals</a><br>
[6] <a href="http://flask.pocoo.org/" rel="noreferrer" target="_blank">http://flask.pocoo.org/</a><br>
[7] <a href="https://review.openstack.org/#/c/329151/10/nova/api/openstack/placement/handlers/resource_provider.py" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/329151/10/nova/api/openstack/placement/handlers/resource_provider.py</a><br>
[8] <a href="https://pypi.python.org/pypi/selector" rel="noreferrer" target="_blank">https://pypi.python.org/pypi/selector</a><br>
[9] <a href="https://review.openstack.org/#/c/329386/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/329386/</a><span class=""><font color="#888888"><br>
<br>
-- <br>
Chris Dent (╯°□°)╯︵┻━┻ <a href="http://anticdent.org/" rel="noreferrer" target="_blank">http://anticdent.org/</a><br>
freenode: cdent tw: @anticdent</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <br><div><div dir="ltr"><div>Kind Regards,</div><div>Andrey Volkov,</div><div>Software Engineer, Mirantis, Inc.</div><div><br></div><div>Tel.: +7 (916) 86 88 942<br></div><div>Skype: amadev_alt<br></div></div></div></div></div>
</div></div>