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
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
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,
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
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
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
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
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
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
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
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
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
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
13 matches
Mail list logo