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

[Jay Pipes]

On 06/20/2016 12:47 PM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2016-06-20 10:04:06 -0400:

On 06/17/2016 11:23 AM, Sylvain Bauza wrote:

+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.


We shouldn't be implementing a WSGI server *at all*. The fact that one
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, uwsgi,
etc) is a bad thing.


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 ?

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 ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken
in a framework-less implementation with nothing other than the (tiny)
selector library as a dependency. I'd like to see the work move forward.

Best,
-jay



It seems like choosing to avoid an existing framework is just going
to eventually result in another new framework evolving organically
as things like common aspects like error handling and transactions
are refactored out of of individual handlers.


WSGI frameworks shouldn't be handling transactions, IMHO. That's a ba d 
coupling problem.


And no, I don't believe this will result in a new framework being 
created, precisely for the reason that no such framework is needed...



Is it really so bad to just pick a tool already being used in some
portion of the rest of the community?


As I said, I'm OK with using Routes since it's already in g-r, but I 
just don't see a need for a WSGI framework, especially one that includes 
things like a WSGI server.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2016-06-20 10:04:06 -0400:
> On 06/17/2016 11:23 AM, Sylvain Bauza wrote:
> > +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.
> 
> We shouldn't be implementing a WSGI server *at all*. The fact that one 
> cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, uwsgi, 
> etc) is a bad thing.
> 
> > 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 ?
> >
> > 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 ?
> >
> > If that is a problem for those, is there something we could improve,
> > instead of just getting rid of it ?
> 
> For the record, I'm very much in favor of the approach Chris has taken 
> in a framework-less implementation with nothing other than the (tiny) 
> selector library as a dependency. I'd like to see the work move forward.
> 
> Best,
> -jay
> 

It seems like choosing to avoid an existing framework is just going
to eventually result in another new framework evolving organically
as things like common aspects like error handling and transactions
are refactored out of of individual handlers.

Is it really so bad to just pick a tool already being used in some
portion of the rest of the community?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Pipes]

On 06/20/2016 10:21 AM, Sylvain Bauza wrote:

Le 20/06/2016 16:04, Jay Pipes a écrit :

On 06/17/2016 11:23 AM, Sylvain Bauza wrote:

+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.


We shouldn't be implementing a WSGI server *at all*. The fact that one
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi,
uwsgi, etc) is a bad thing.



Okay, fair point :-)
That still leaves the routing question up, tho :-)

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 ?

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 ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken
in a framework-less implementation with nothing other than the (tiny)
selector library as a dependency. I'd like to see the work move forward.



Okay, my open question (because I'm not expert in that) was rather to
understand why Routes was not possible to be something usable for the
new placement API, if that's something we use in Nova too.


Routes would indeed be possible to use. And I wouldn't have an issue 
using Routes, though I prefer selector due to its simplicity and 
documentation readability and that controllers are specified as actual 
callables, not strings.


-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sylvain Bauza]

Le 20/06/2016 16:04, Jay Pipes a écrit :

On 06/17/2016 11:23 AM, Sylvain Bauza wrote:

+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.


We shouldn't be implementing a WSGI server *at all*. The fact that one 
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, 
uwsgi, etc) is a bad thing.




Okay, fair point :-)
That still leaves the routing question up, tho :-)

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 ?

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 ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken 
in a framework-less implementation with nothing other than the (tiny) 
selector library as a dependency. I'd like to see the work move forward.




Okay, my open question (because I'm not expert in that) was rather to 
understand why Routes was not possible to be something usable for the 
new placement API, if that's something we use in Nova too.


-S


Best,
-jay

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay Pipes]

On 06/17/2016 11:23 AM, Sylvain Bauza wrote:

+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.


We shouldn't be implementing a WSGI server *at all*. The fact that one 
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, uwsgi, 
etc) is a bad thing.



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 ?

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 ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken 
in a framework-less implementation with nothing other than the (tiny) 
selector library as a dependency. I'd like to see the work move forward.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sean Dague]

On 06/17/2016 12:14 PM, Chris Dent wrote:
> On Fri, 17 Jun 2016, Sylvain Bauza wrote:
> 
>> 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 ?
> 
> The implication of your question here is that it is okay to do HTTP
> incorrectly if people don't report problems with that lack of
> correctness?
>
>> If that is a problem for those, is there something we could improve,
>> instead of just getting rid of it ?
> 
> When I found the initial problem with Routes, it was because I was
> doing some intial nova testing (with gabbi-tempest[1]) and
> discovered it wasn't returning a 405 when it should. I made a bug
> 
> https://bugs.launchpad.net/nova/+bug/1567970
> 
> and tried to fix it but Routes fought me. If someone else can figure
> it out more power to them.
> 
> In any case selector's behavior in this case is just better. Better
> is better, right?

That's a Nova bug, is there an upstream Routes bug for that? I didn't
see one in looking around. While Routes isn't a super quick upstream,
they have merged our fixes in the past.

Better on what axis? This does add another way that people need to learn
to do this thing that they've all been doing another way. Largely to
address a set of issues that are theoretical to our consumers.
http://mcfunley.com/choose-boring-technology

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sylvain Bauza]

Le 17/06/2016 18:11, Dean Troyer a écrit :
On Fri, Jun 17, 2016 at 10:23 AM, Sylvain Bauza > wrote:


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 ?


I feel a bit compelled to say that the assumption that the API 
consumers are mostly 'our code' is a faulty one and not true.  Just 
within the collection of client projects in the openstack/ repo 
namespace, there are at least 4 different codebases talking to compute 
endpoints.


I'm not picking on you Sylvain, this is just something that I think 
needs periodic reinforcement among our developer community.




No worries at all, Dean. Thanks for explaining your opinion. To be 
clear, I used "we" for saying "We are OpenStack", ie. an excellent 
ecosystem.




dt

--

Dean Troyer
dtro...@gmail.com 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Chris Dent]

On Fri, 17 Jun 2016, Sylvain Bauza wrote:

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 ?


The implication of your question here is that it is okay to do HTTP
incorrectly if people don't report problems with that lack of
correctness?

If that is a problem for those, is there something we could improve, instead 
of just getting rid of it ?


When I found the initial problem with Routes, it was because I was
doing some intial nova testing (with gabbi-tempest[1]) and
discovered it wasn't returning a 405 when it should. I made a bug

https://bugs.launchpad.net/nova/+bug/1567970

and tried to fix it but Routes fought me. If someone else can figure
it out more power to them.

In any case selector's behavior in this case is just better. Better
is better, right?


--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Dean Troyer]

On Fri, Jun 17, 2016 at 10:23 AM, Sylvain Bauza  wrote:
>
> 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 ?
>

I feel a bit compelled to say that the assumption that the API consumers
are mostly 'our code' is a faulty one and not true.  Just within the
collection of client projects in the openstack/ repo namespace, there are
at least 4 different codebases talking to compute endpoints.

I'm not picking on you Sylvain, this is just something that I think needs
periodic reinforcement among our developer community.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Chris Dent]

On Fri, 17 Jun 2016, Andrey Volkov wrote:


IMHO selector is too young in terms of version (0.1) and too old in
terms of updates (3 years ago).


It's 0.10. When I contacted the author (see the comments on 
https://review.openstack.org/#/c/329386/ ) he said the reason there

were no recent releases is because nothing was broken and he is
continuing to actively use and maintain it.


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.


In this particular case async would be overkill and out of place.
The changes being made in the requests are quick and in an important
transaction.


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


Rather than me describing it, perhaps have a look at
https://review.openstack.org/#/c/329151/10/nova/tests/functional/api/openstack/placement/gabbits/resource-provider.yaml
and then ask questions if you have any? I think that does a
relatively good job demonstrating the declarative style.

--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Sylvain Bauza]

Le 17/06/2016 12:55, Chris Dent a écrit :


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.



+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.
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 :-)




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].



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 ?


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 ?


If that is a problem for those, is there something we could improve, 
instead of just getting rid of it ?


-Sylvain


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] 

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

[Andrey Volkov]

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
API.

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  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]
> 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]
> 

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

[Chris Dent]

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__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev