[openstack-dev] [nova] [api] [placement] strategy for placement api structure

Andrey Volkov avolkov at mirantis.com
Fri Jun 17 14:24:49 UTC 2016

It's nice to hear about HTTP API.
I'm quite new in nova and openstack and don't grasp all that rpc
things yet and can miss something but anyway I have several thoughts about

Boring standpoint. First to choose some technology I think we can look at
how widely
it's adopted and how many people at local community (openstack)
use it. I checked out several openstack projects (keystone, swift,
cinder) and it's Paste I think.
IMHO selector is too young in terms of version (0.1) and too old in
terms of updates (3 years ago).

Idea. I absolutely agree with you about flask and his magic.
And if we want to start totally new it can be werkzeug or webob.
And if we go further I wonder why in nova we don't use
asynchronous approach. All these API calls which just transfer
from one point to another are perfect candidates.

About API. It would be great for new service to have auto schema
description/validation and may be some optional stuff like duplicate
protection, call signature.

About gabbi. Could you please give several procs on declarative style
in yaml vs declarative style in python?

On Fri, Jun 17, 2016 at 1:55 PM, Chris Dent <cdent+os at anticdent.org> wrote:

> 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]
> 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
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Kind Regards,
Andrey Volkov,
Software Engineer, Mirantis, Inc.

Tel.: +7 (916) 86 88 942
Skype: amadev_alt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160617/ab28124a/attachment.html>

More information about the OpenStack-dev mailing list