Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

[Edison Xiang]

Hi team,

I submit a forum [1] named "Cross-project Open API 3.0 support".
We can make more discussions about that in this forum in berlin.
Feel free to add your ideas here [2].
Welcome to join us.
Thanks very much.

[1]
https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=open+api
[2] https://etherpad.openstack.org/p/api-berlin-forum-brainstorming


Best Regards,
Edison Xiang

On Thu, Oct 11, 2018 at 7:48 PM Gilles Dubreuil  wrote:

>
>
> On 11/10/18 00:18, Jeremy Stanley wrote:
>
> On 2018-10-10 13:24:28 +1100 (+1100), Gilles Dubreuil wrote:
>
> On 09/10/18 23:58, Jeremy Stanley wrote:
>
> On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
> [...]
>
> It seems to me that a major goal of openstacksdk is to hide
> differences between clouds from the user. If the user is meant
> to use a GraphQL library themselves, we lose this and the user
> needs to figure it out themselves. Did I understand that
> correctly?
>
> This is especially useful where the SDK implements business
> logic for common operations like "if the user requested A and
> the cloud supports features B+C+D then use those to fulfil the
> request, otherwise fall back to using features E+F".
>
>
> The features offered to the user don't have to change, it's just a
> different architecture.
>
> The user doesn't have to deal with a GraphQL library, only the
> client applications (consuming OpenStack APIs). And there are also
> UI tools such as GraphiQL which allow to interact directly with
> GraphQL servers.
>
>
> My point was simply that SDKs provide more than a simple translation
> of network API calls and feature discovery. There can also be rather
> a lot of "business logic" orchestrating multiple primitive API calls
> to reach some more complex outcome. The services don't want to embed
> this orchestrated business logic themselves, and it makes little
> sense to replicate the same algorithms in every single application
> which wants to make use of such composite functionality. There are
> common actions an application might wish to take which involve
> speaking to multiple APIs for different services to make specific
> calls in a particular order, perhaps feeding the results of one into
> the next.
>
> Can you explain how GraphQL eliminates the above reasons for an SDK?
>
>
> What I meant is the communication part of any SDK interfacing between
> clients and API services can be handled by GraphQL client librairies.
> So instead of having to rely on modules (imported or native) to carry the
> REST communications, we're dealing with data provided by GraphQL libraries
> (which are also modules but standardized as GraphQL is a specification).
> So as you mentioned there is still need to provide the data wrap in
> objects or any adequate struct to present to the consumers.
>
> Having a Schema helps both API and clients developers because the data is
> clearly typed and graphed. Backend devs can focus on resolving the data for
> each node/leaf while the clients can focus on what they need and not how to
> get it.
>
> To relate to $subject, by building the data model (graph) we obtain a
> schema and introspection. That's a big saver in term of resources.
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
__
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] [api] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

On 11/10/18 00:18, Jeremy Stanley wrote:

On 2018-10-10 13:24:28 +1100 (+1100), Gilles Dubreuil wrote:

On 09/10/18 23:58, Jeremy Stanley wrote:

On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
[...]

It seems to me that a major goal of openstacksdk is to hide
differences between clouds from the user. If the user is meant
to use a GraphQL library themselves, we lose this and the user
needs to figure it out themselves. Did I understand that
correctly?

This is especially useful where the SDK implements business
logic for common operations like "if the user requested A and
the cloud supports features B+C+D then use those to fulfil the
request, otherwise fall back to using features E+F".

The features offered to the user don't have to change, it's just a
different architecture.

The user doesn't have to deal with a GraphQL library, only the
client applications (consuming OpenStack APIs). And there are also
UI tools such as GraphiQL which allow to interact directly with
GraphQL servers.

My point was simply that SDKs provide more than a simple translation
of network API calls and feature discovery. There can also be rather
a lot of "business logic" orchestrating multiple primitive API calls
to reach some more complex outcome. The services don't want to embed
this orchestrated business logic themselves, and it makes little
sense to replicate the same algorithms in every single application
which wants to make use of such composite functionality. There are
common actions an application might wish to take which involve
speaking to multiple APIs for different services to make specific
calls in a particular order, perhaps feeding the results of one into
the next.

Can you explain how GraphQL eliminates the above reasons for an SDK?


What I meant is the communication part of any SDK interfacing between 
clients and API services can be handled by GraphQL client librairies.
So instead of having to rely on modules (imported or native) to carry 
the REST communications, we're dealing with data provided by GraphQL 
libraries (which are also modules but standardized as GraphQL is a 
specification).
So as you mentioned there is still need to provide the data wrap in 
objects or any adequate struct to present to the consumers.


Having a Schema helps both API and clients developers because the data 
is clearly typed and graphed. Backend devs can focus on resolving the 
data for each node/leaf while the clients can focus on what they need 
and not how to get it.


To relate to $subject, by building the data model (graph) we obtain a 
schema and introspection. That's a big saver in term of resources.







__
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] [api] Open API 3.0 for OpenStack API

[Jeremy Stanley]

On 2018-10-10 13:24:28 +1100 (+1100), Gilles Dubreuil wrote:
> On 09/10/18 23:58, Jeremy Stanley wrote:
> > On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
> > [...]
> > > It seems to me that a major goal of openstacksdk is to hide
> > > differences between clouds from the user. If the user is meant
> > > to use a GraphQL library themselves, we lose this and the user
> > > needs to figure it out themselves. Did I understand that
> > > correctly?
> > This is especially useful where the SDK implements business
> > logic for common operations like "if the user requested A and
> > the cloud supports features B+C+D then use those to fulfil the
> > request, otherwise fall back to using features E+F".
> 
> The features offered to the user don't have to change, it's just a
> different architecture.
> 
> The user doesn't have to deal with a GraphQL library, only the
> client applications (consuming OpenStack APIs). And there are also
> UI tools such as GraphiQL which allow to interact directly with
> GraphQL servers.

My point was simply that SDKs provide more than a simple translation
of network API calls and feature discovery. There can also be rather
a lot of "business logic" orchestrating multiple primitive API calls
to reach some more complex outcome. The services don't want to embed
this orchestrated business logic themselves, and it makes little
sense to replicate the same algorithms in every single application
which wants to make use of such composite functionality. There are
common actions an application might wish to take which involve
speaking to multiple APIs for different services to make specific
calls in a particular order, perhaps feeding the results of one into
the next.

Can you explain how GraphQL eliminates the above reasons for an SDK?
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [api] Open API 3.0 for OpenStack API

[Jim Rollenhagen]

On Tue, Oct 9, 2018 at 10:25 PM Gilles Dubreuil  wrote:

>
>
> On 09/10/18 23:58, Jeremy Stanley wrote:
> > On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
> > [...]
> >> It seems to me that a major goal of openstacksdk is to hide differences
> >> between clouds from the user. If the user is meant to use a GraphQL
> library
> >> themselves, we lose this and the user needs to figure it out themselves.
> >> Did I understand that correctly?
> > This is especially useful where the SDK implements business logic
> > for common operations like "if the user requested A and the cloud
> > supports features B+C+D then use those to fulfil the request,
> > otherwise fall back to using features E+F".
> >
>
> The features offered to the user don't have to change, it's just a
> different architecture.
>
> The user doesn't have to deal with a GraphQL library, only the client
> applications (consuming OpenStack APIs).
> And there are also UI tools such as GraphiQL which allow to interact
> directly with GraphQL servers.
>

Right, this comes back to what I said earlier:

> That said, it seems like using this in a client like OpenStackSDK would
get messy quickly. Instead of asking for which versions are supported,
you'd have to fetch the schema, map it to actual features somehow, and
adjust queries based on this info.
>
> I guess there might be a middleground where we could fetch the REST API
version, and know from that what GraphQL queries can be made.

This isn't unsolvable, but it does sound like quite a bit of work. This
isn't to say "let's not do graphql at all", but it's important to
understand the work involved.

FWIW, I originally mentioned the SDK (as opposed to the clients speaking
graphql directly), as the client applications are currently transitioning
to use openstacksdk instead of their own API calls.

// jim

>
>
> __
> 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] [api] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

On 09/10/18 23:58, Jeremy Stanley wrote:

On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
[...]

It seems to me that a major goal of openstacksdk is to hide differences
between clouds from the user. If the user is meant to use a GraphQL library
themselves, we lose this and the user needs to figure it out themselves.
Did I understand that correctly?

This is especially useful where the SDK implements business logic
for common operations like "if the user requested A and the cloud
supports features B+C+D then use those to fulfil the request,
otherwise fall back to using features E+F".



The features offered to the user don't have to change, it's just a 
different architecture.


The user doesn't have to deal with a GraphQL library, only the client 
applications (consuming OpenStack APIs).
And there are also UI tools such as GraphiQL which allow to interact 
directly with GraphQL servers.



__
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] [api] Open API 3.0 for OpenStack API

[Jeremy Stanley]

On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote:
[...]
> It seems to me that a major goal of openstacksdk is to hide differences
> between clouds from the user. If the user is meant to use a GraphQL library
> themselves, we lose this and the user needs to figure it out themselves.
> Did I understand that correctly?

This is especially useful where the SDK implements business logic
for common operations like "if the user requested A and the cloud
supports features B+C+D then use those to fulfil the request,
otherwise fall back to using features E+F".
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [api] Open API 3.0 for OpenStack API

[Jim Rollenhagen]

On Mon, Oct 8, 2018 at 5:58 AM Gilles Dubreuil  wrote:

>
> On 05/10/18 21:54, Jim Rollenhagen wrote:
>
> GraphQL has introspection features that allow clients to pull the schema
> (types, queries, mutations, etc): https://graphql.org/learn/introspection/
>
> That said, it seems like using this in a client like OpenStackSDK would
> get messy quickly. Instead of asking for which versions are supported,
> you'd have to fetch the schema, map it to actual features somehow, and
> adjust queries based on this info.
>
>
> A main difference in software architecture when using GraphQL is that a
> client makes use of a GraphQL client library instead of relaying on a SDK.
>

It seems to me that a major goal of openstacksdk is to hide differences
between clouds from the user. If the user is meant to use a GraphQL library
themselves, we lose this and the user needs to figure it out themselves.
Did I understand that correctly?

// jim
__
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] [api] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

On 05/10/18 21:54, Jim Rollenhagen wrote:
GraphQL has introspection features that allow clients to pull the 
schema (types, queries, mutations, etc): 
https://graphql.org/learn/introspection/


That said, it seems like using this in a client like OpenStackSDK 
would get messy quickly. Instead of asking for which versions are 
supported, you'd have to fetch the schema, map it to actual features 
somehow, and adjust queries based on this info.




A main difference in software architecture when using GraphQL is that a 
client makes use of a GraphQL client library instead of relaying on a SDK.



I guess there might be a middleground where we could fetch the REST 
API version, and know from that what GraphQL queries can be made.


// jim



__
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] [api] Open API 3.0 for OpenStack API

[Jim Rollenhagen]

GraphQL has introspection features that allow clients to pull the schema
(types, queries, mutations, etc): https://graphql.org/learn/introspection/

That said, it seems like using this in a client like OpenStackSDK would get
messy quickly. Instead of asking for which versions are supported, you'd
have to fetch the schema, map it to actual features somehow, and adjust
queries based on this info.

I guess there might be a middleground where we could fetch the REST API
version, and know from that what GraphQL queries can be made.

// jim


On Fri, Oct 5, 2018 at 7:30 AM Doug Hellmann  wrote:

> Gilles Dubreuil  writes:
>
> >> About the micro version, we discuss with your team mate dmitry in
> >> another email [1]
> >
> > Obviously micro version is a point of contention.
> > My take on this is because consuming them has been proven harder than
> > developing them.
> > The beauty of GraphQL is that there is no need to deal with version at
> all.
> > New fields appears when needed and old one are marked deprecated.
>
> How does someone using GraphQL to use a cloud know when a specific field
> is available? How can they differentiate what is supported in one cloud
> from what is supported in another, running a different version of the
> same service?
>
> 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
>
__
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] [api] Open API 3.0 for OpenStack API

[Doug Hellmann]

Gilles Dubreuil  writes:

>> About the micro version, we discuss with your team mate dmitry in 
>> another email [1]
>
> Obviously micro version is a point of contention.
> My take on this is because consuming them has been proven harder than 
> developing them.
> The beauty of GraphQL is that there is no need to deal with version at all.
> New fields appears when needed and old one are marked deprecated.

How does someone using GraphQL to use a cloud know when a specific field
is available? How can they differentiate what is supported in one cloud
from what is supported in another, running a different version of the
same service?

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] [api] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

Hi Edison,

Sorry for the delay.

Please see inline...

Cheers,
Gilles

On 07/09/18 12:03, Edison Xiang wrote:

Hey gilles,

Thanks your introduction for GraphQL and Relay.

> GraphQL and OpenAPI have a different feature scope and both have pros and 
cons.

I totally agree with you. They can work together.
Right now, I think we have no more work to adapt OpenStack APIs for 
Open API.
Firstly we could sort out Open API schemas base on the current 
OpenStack APIs.

and then we can discuss how to use it.


I think a big question is going to be about the effort required to bring 
OpenStack API to be Open API v3.0 compliant.
This is challenging because the various projects involved and the need 
to validate a new solution across all the projects.
The best approach is likely to first demonstrate a new solution is 
viable and then eventually bring it to be accepted globally.
Also because we don't have unlimited resources, I doubt we're going to 
be able to bring both Open API and GraphQL to the table(s).


There no doubts how OpenStack APIs can benefit from features such as 
schema definitions, self documentation and better performance especially 
if they are built-in or derived from a standard.
Meanwhile a practical example shows those features in action (for the 
skeptical) but also demonstrate how to do it which clarify the effort 
involved along with pros and cons.I want to make clear that I'm not 
against OpenAPI, I was actually keen to get it on board because of the 
benefits


And it will also helps compare solutions (Open API, GraphQL).

So, what do you think about an Open API proof of concept with Neutron?


About the micro version, we discuss with your team mate dmitry in 
another email [1]


Obviously micro version is a point of contention.
My take on this is because consuming them has been proven harder than 
developing them.

The beauty of GraphQL is that there is no need to deal with version at all.
New fields appears when needed and old one are marked deprecated.




[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134202.html


Best Regards,
Edison Xiang

On Tue, Sep 4, 2018 at 8:37 AM Gilles Dubreuil > wrote:




On 30/08/18 13:56, Edison Xiang wrote:

Hi Ed Leafe,

Thanks your reply.
Open API defines a standard interface description for REST APIs.
Open API 3.0 can make a description(schema) for current OpenStack
REST API.
It will not change current OpenStack API.
I am not a GraphQL expert. I look up something about GraphQL.
In my understanding, GraphQL will get current OpenAPI together
and provide another APIs based on Relay,


Not sure what you mean here, could you please develop?



and Open API is used to describe REST APIs and GraphQL is used to
describe Relay APIs.


There is no such thing as "Relay APIs".
GraphQL povides a de-facto API Schema and Relay provides
extensions on top to facilitate re-fetching, paging and more.
GraphQL and OpenAPI have a different feature scope and both have
pros and cons.
GraphQL is delivering API without using REST verbs as all requests
are undone using POST and its data.
Beyond that what would be great (and it will ultimately come) is
to have both of them working together.

The idea of the GraphQL Proof of Concept is see what it can bring
and at what cost such as effort and trade-offs.
And to compare this against the effort to adapt OpenStack APIs to
use Open API.

BTW what's the status of Open API 3.0 in regards of Microversion?

Regards,
Gilles



Best Regards,
Edison Xiang

On Wed, Aug 29, 2018 at 9:33 PM Ed Leafe mailto:e...@leafe.com>> wrote:

On Aug 29, 2018, at 1:36 AM, Edison Xiang
mailto:xiang.edi...@gmail.com>> wrote:
>
> As we know, Open API 3.0 was released on July, 2017, it is
about one year ago.
> Open API 3.0 support some new features like anyof, oneof
and allof than Open API 2.0(Swagger 2.0).
> Now OpenStack projects do not support Open API.
> Also I found some old emails in the Mail List about
supporting Open API 2.0 in OpenStack.

There is currently an effort by some developers to
investigate the possibility of using GraphQL with OpenStack
APIs. What would Open API 3.0 provide that GraphQL would not?
I’m asking because I don’t know enough about Open API to
compare them.


-- Ed Leafe







__
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] [api] Open API 3.0 for OpenStack API

[Edison Xiang]

Hey gilles,

Thanks your introduction for GraphQL and Relay.

> GraphQL and OpenAPI have a different feature scope and both have pros and
cons.

I totally agree with you. They can work together.
Right now, I think we have no more work to adapt OpenStack APIs for Open
API.
Firstly we could sort out Open API schemas base on the current OpenStack
APIs.
and then we can discuss how to use it.
About the micro version, we discuss with your team mate dmitry in another
email [1]

[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134202.html

Best Regards,
Edison Xiang

On Tue, Sep 4, 2018 at 8:37 AM Gilles Dubreuil  wrote:

>
>
> On 30/08/18 13:56, Edison Xiang wrote:
>
> Hi Ed Leafe,
>
> Thanks your reply.
> Open API defines a standard interface description for REST APIs.
> Open API 3.0 can make a description(schema) for current OpenStack REST API.
> It will not change current OpenStack API.
> I am not a GraphQL expert. I look up something about GraphQL.
> In my understanding, GraphQL will get current OpenAPI together and provide
> another APIs based on Relay,
>
>
> Not sure what you mean here, could you please develop?
>
>
> and Open API is used to describe REST APIs and GraphQL is used to describe
> Relay APIs.
>
>
> There is no such thing as "Relay APIs".
> GraphQL povides a de-facto API Schema and Relay provides extensions on top
> to facilitate re-fetching, paging and more.
> GraphQL and OpenAPI have a different feature scope and both have pros and
> cons.
> GraphQL is delivering API without using REST verbs as all requests are
> undone using POST and its data.
> Beyond that what would be great (and it will ultimately come) is to have
> both of them working together.
>
> The idea of the GraphQL Proof of Concept is see what it can bring and at
> what cost such as effort and trade-offs.
> And to compare this against the effort to adapt OpenStack APIs to use Open
> API.
>
> BTW what's the status of Open API 3.0 in regards of Microversion?
>
> Regards,
> Gilles
>
>
> Best Regards,
> Edison Xiang
>
> On Wed, Aug 29, 2018 at 9:33 PM Ed Leafe  wrote:
>
>> On Aug 29, 2018, at 1:36 AM, Edison Xiang  wrote:
>> >
>> > As we know, Open API 3.0 was released on July, 2017, it is about one
>> year ago.
>> > Open API 3.0 support some new features like anyof, oneof and allof than
>> Open API 2.0(Swagger 2.0).
>> > Now OpenStack projects do not support Open API.
>> > Also I found some old emails in the Mail List about supporting Open API
>> 2.0 in OpenStack.
>>
>> There is currently an effort by some developers to investigate the
>> possibility of using GraphQL with OpenStack APIs. What would Open API 3.0
>> provide that GraphQL would not? I’m asking because I don’t know enough
>> about Open API to compare them.
>>
>>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>>
>> __
>> 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Gilles Dubreuil
> Senior Software Engineer - Red Hat - Openstack DFG Integration
> Email: gil...@redhat.com
> GitHub/IRC: gildub
> Mobile: +61 400 894 219
>
>
>
__
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] [api] Open API 3.0 for OpenStack API

[Edison Xiang]

Hi Dmitry,

Thanks your reply. Absolutely you are a sdk expert.

> This is a good first step, but if I get it right it does not specify
which
> response corresponds to which request.

You got it. I think it depends on how to use the API schemas.
We could define some rules to make sure which response corresponds to which
request.
For example, by order. Maybe you can give some other suggestions.
Also, this is not fresh concept, we can find the choice definition in xsd
[1].
By the way, firstly we can sort out OpenStack API schemas ,
and handle these schemas to the developers and the users,
and let them to choose how to use it.

[1] https://www.w3schools.com/xml/el_choice.asp

Best Regards,
Edison Xiang

On Tue, Sep 4, 2018 at 7:01 PM Dmitry Tantsur  wrote:

> Hi,
>
> On 08/29/2018 08:36 AM, Edison Xiang wrote:
> > Hi team,
> >
> > As we know, Open API 3.0 was released on July, 2017, it is about one
> year ago.
> > Open API 3.0 support some new features like anyof, oneof and allof than
> Open API
> > 2.0(Swagger 2.0).
> > Now OpenStack projects do not support Open API.
> > Also I found some old emails in the Mail List about supporting Open API
> 2.0 in
> > OpenStack.
> >
> > Some limitations are mentioned in the Mail List for OpenStack API:
> > 1. The POST */action APIs.
> >  These APIs are exist in lots of projects like nova, cinder.
> >  These APIs have the same URI but the responses will be different
> when the
> > request is different.
> > 2. Micro versions.
> >  These are controller via headers, which are sometimes used to
> describe
> > behavioral changes in an API, not just request/response schema changes.
> >
> > About the first limitation, we can find the solution in the Open API 3.0.
> > The example [2] shows that we can define different request/response in
> the same
> > URI by anyof feature in Open API 3.0.
>
> This is a good first step, but if I get it right it does not specify which
> response corresponds to which request.
>
> >
> > About the micro versions problem, I think it is not a limitation related
> a
> > special API Standard.
> > We can list all micro versions API schema files in one directory like
> nova/V2,
>
> I don't think this approach will scale if you plan to generate anything
> based on
> these schemes. If you generate client code from separate schema files,
> you'll
> essentially end up with dozens of major versions.
>
> > or we can list the schema changes between micro versions as tempest
> project did [3].
>
> ++
>
> >
> > Based on Open API 3.0, it can bring lots of benefits for OpenStack
> Community and
> > does not impact the current features the Community has.
> > For example, we can automatically generate API documents, different
> language
> > Clients(SDK) maybe for different micro versions,
>
>  From my experience with writing an SDK, I don't believe generating a
> complete
> SDK from API schemes is useful. Maybe generating low-level protocol code
> to base
> an SDK on, but even that may be easier to do by hand.
>
> Dmitry
>
> > and generate cloud tool adapters for OpenStack, like ansible module,
> terraform
> > providers and so on.
> > Also we can make an API UI to provide an online and visible API search,
> API
> > Calling for every OpenStack API.
> > 3rd party developers can also do some self-defined development.
> >
> > [1] https://github.com/OAI/OpenAPI-Specification
> > [2]
> >
> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
> > [3]
> >
> https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute
> >
> > Best Regards,
> > Edison Xiang
> >
> >
> >
> >
> __
> > 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
>
__
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-dev] [api] microversion-parse core updates

[Chris Dent]

After some discussion with other cores I've made some adjustments to
the core team on microversion-parse [1]

* added dtantsur (welcome!)
* removed sdague

In case you're not aware, microversion-parse is middleware and
utilities for managing microversions in openstack service apis.

[1] https://pypi.org/project/microversion_parse/
http://git.openstack.org/cgit/openstack/microversion-parse

--
Chris Dent   ٩◔̯◔۶   https://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] [api] Open API 3.0 for OpenStack API

[Dmitry Tantsur]

Hi,

On 08/29/2018 08:36 AM, Edison Xiang wrote:

Hi team,

As we know, Open API 3.0 was released on July, 2017, it is about one year ago.
Open API 3.0 support some new features like anyof, oneof and allof than Open API 
2.0(Swagger 2.0).

Now OpenStack projects do not support Open API.
Also I found some old emails in the Mail List about supporting Open API 2.0 in 
OpenStack.


Some limitations are mentioned in the Mail List for OpenStack API:
1. The POST */action APIs.
     These APIs are exist in lots of projects like nova, cinder.
     These APIs have the same URI but the responses will be different when the 
request is different.

2. Micro versions.
     These are controller via headers, which are sometimes used to describe 
behavioral changes in an API, not just request/response schema changes.


About the first limitation, we can find the solution in the Open API 3.0.
The example [2] shows that we can define different request/response in the same 
URI by anyof feature in Open API 3.0.


This is a good first step, but if I get it right it does not specify which 
response corresponds to which request.




About the micro versions problem, I think it is not a limitation related a 
special API Standard.

We can list all micro versions API schema files in one directory like nova/V2,


I don't think this approach will scale if you plan to generate anything based on 
these schemes. If you generate client code from separate schema files, you'll 
essentially end up with dozens of major versions.



or we can list the schema changes between micro versions as tempest project did 
[3].


++



Based on Open API 3.0, it can bring lots of benefits for OpenStack Community and 
does not impact the current features the Community has.
For example, we can automatically generate API documents, different language 
Clients(SDK) maybe for different micro versions,


From my experience with writing an SDK, I don't believe generating a complete 
SDK from API schemes is useful. Maybe generating low-level protocol code to base 
an SDK on, but even that may be easier to do by hand.


Dmitry

and generate cloud tool adapters for OpenStack, like ansible module, terraform 
providers and so on.
Also we can make an API UI to provide an online and visible API search, API 
Calling for every OpenStack API.

3rd party developers can also do some self-defined development.

[1] https://github.com/OAI/OpenAPI-Specification
[2] 
https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
[3] 
https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute


Best Regards,
Edison Xiang



__
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] [api] Open API 3.0 for OpenStack API

[Gilles Dubreuil]

On 30/08/18 13:56, Edison Xiang wrote:

Hi Ed Leafe,

Thanks your reply.
Open API defines a standard interface description for REST APIs.
Open API 3.0 can make a description(schema) for current OpenStack REST 
API.

It will not change current OpenStack API.
I am not a GraphQL expert. I look up something about GraphQL.
In my understanding, GraphQL will get current OpenAPI together and 
provide another APIs based on Relay,


Not sure what you mean here, could you please develop?


and Open API is used to describe REST APIs and GraphQL is used to 
describe Relay APIs.


There is no such thing as "Relay APIs".
GraphQL povides a de-facto API Schema and Relay provides extensions on 
top to facilitate re-fetching, paging and more.
GraphQL and OpenAPI have a different feature scope and both have pros 
and cons.
GraphQL is delivering API without using REST verbs as all requests are 
undone using POST and its data.
Beyond that what would be great (and it will ultimately come) is to have 
both of them working together.


The idea of the GraphQL Proof of Concept is see what it can bring and at 
what cost such as effort and trade-offs.
And to compare this against the effort to adapt OpenStack APIs to use 
Open API.


BTW what's the status of Open API 3.0 in regards of Microversion?

Regards,
Gilles



Best Regards,
Edison Xiang

On Wed, Aug 29, 2018 at 9:33 PM Ed Leafe > wrote:


On Aug 29, 2018, at 1:36 AM, Edison Xiang mailto:xiang.edi...@gmail.com>> wrote:
>
> As we know, Open API 3.0 was released on July, 2017, it is about
one year ago.
> Open API 3.0 support some new features like anyof, oneof and
allof than Open API 2.0(Swagger 2.0).
> Now OpenStack projects do not support Open API.
> Also I found some old emails in the Mail List about supporting
Open API 2.0 in OpenStack.

There is currently an effort by some developers to investigate the
possibility of using GraphQL with OpenStack APIs. What would Open
API 3.0 provide that GraphQL would not? I’m asking because I don’t
know enough about Open API to compare them.


-- Ed Leafe






__
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


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
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] [api] Open API 3.0 for OpenStack API

[Edison Xiang]

Hey doug,

Thanks your reply. Very good question.
It is not a conflict with current API Documents work that has already been
done.
We can use some tools to generate Open API schema from existing machine
readable API-def in every project like nova [1]
We can still use the existing tools to generate the API Documents website.

[1] https://github.com/openstack/nova/tree/master/api-ref/source

Best Regards,
Edison Xiang

On Fri, Aug 31, 2018 at 1:46 AM Doug Hellmann  wrote:

> Excerpts from Edison Xiang's message of 2018-08-30 14:08:12 +0800:
> > Hey dims,
> >
> > Thanks your reply. Your suggestion is very important.
> >
> > > what would be the impact to projects?
> > > what steps they would have to take?
> >
> > We can launch a project to publish OpenStack Projects APIs Schema for
> users
> > and  developers.
> > But now OpenStack Projects have no APIs Schema definition.
> > Open API will not impact OpenStack Projects features they have,
> > but we need some volunteers to define every project APIs Schema by Open
> API
> > 3.0.
> >
> > > Do we have a sample/mock API where we can show that the Action and
> > Microversions can be declared to reflect reality and it can actually work
> > with the generated code?
> > Yeah, you can copy this yaml [1] into editor [2] to generate server or
> > client codes or try it out.
> > We can do more demos later.
> >
> > [1]
> >
> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml
> > [2] https://editor.swagger.io
> >
> > Best Regards,
> > Edison Xiang
>
> How does this proposal relate to the work that has already been
> done to build the API guide
> https://developer.openstack.org/api-guide/quick-start/ documentation?
>
> Doug
>
> >
> > On Wed, Aug 29, 2018 at 6:31 PM Davanum Srinivas 
> wrote:
> >
> > > Edison,
> > >
> > > This is definitely a step in the right direction if we can pull it off.
> > >
> > > Given the previous experiences and the current situation of how and
> where
> > > we store the information currently and how we generate the website for
> the
> > > API(s), can you please outline
> > > - what would be the impact to projects?
> > > - what steps they would have to take?
> > >
> > > Also, the whole point of having these definitions is that the generated
> > > code works. Do we have a sample/mock API where we can show that the
> Action
> > > and Microversions can be declared to reflect reality and it can
> actually
> > > work with the generated code?
> > >
> > > Thanks,
> > > Dims
> > >
> > > On Wed, Aug 29, 2018 at 2:37 AM Edison Xiang 
> > > wrote:
> > >
> > >> Hi team,
> > >>
> > >> As we know, Open API 3.0 was released on July, 2017, it is about one
> year
> > >> ago.
> > >> Open API 3.0 support some new features like anyof, oneof and allof
> than
> > >> Open API 2.0(Swagger 2.0).
> > >> Now OpenStack projects do not support Open API.
> > >> Also I found some old emails in the Mail List about supporting Open
> API
> > >> 2.0 in OpenStack.
> > >>
> > >> Some limitations are mentioned in the Mail List for OpenStack API:
> > >> 1. The POST */action APIs.
> > >> These APIs are exist in lots of projects like nova, cinder.
> > >> These APIs have the same URI but the responses will be different
> when
> > >> the request is different.
> > >> 2. Micro versions.
> > >> These are controller via headers, which are sometimes used to
> > >> describe behavioral changes in an API, not just request/response
> schema
> > >> changes.
> > >>
> > >> About the first limitation, we can find the solution in the Open API
> 3.0.
> > >> The example [2] shows that we can define different request/response in
> > >> the same URI by anyof feature in Open API 3.0.
> > >>
> > >> About the micro versions problem, I think it is not a limitation
> related
> > >> a special API Standard.
> > >> We can list all micro versions API schema files in one directory like
> > >> nova/V2,
> > >> or we can list the schema changes between micro versions as tempest
> > >> project did [3].
> > >>
> > >> Based on Open API 3.0, it can bring lots of benefits for OpenStack
> > >> Community and does not impact the current features the  Community has.
> > >> For example, we can automatically generate API documents, different
> > >> language Clients(SDK) maybe for different micro versions,
> > >> and generate cloud tool adapters for OpenStack, like ansible module,
> > >> terraform providers and so on.
> > >> Also we can make an API UI to provide an online and visible API
> search,
> > >> API Calling for every OpenStack API.
> > >> 3rd party developers can also do some self-defined development.
> > >>
> > >> [1] https://github.com/OAI/OpenAPI-Specification
> > >> [2]
> > >>
> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
> > >> [3]
> > >>
> https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute
> > >>
> > >> Best Regards,
> > >> Edison Xiang
> > >>
> > >>
> 

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

[Doug Hellmann]

Excerpts from Edison Xiang's message of 2018-08-30 14:08:12 +0800:
> Hey dims,
> 
> Thanks your reply. Your suggestion is very important.
> 
> > what would be the impact to projects?
> > what steps they would have to take?
> 
> We can launch a project to publish OpenStack Projects APIs Schema for users
> and  developers.
> But now OpenStack Projects have no APIs Schema definition.
> Open API will not impact OpenStack Projects features they have,
> but we need some volunteers to define every project APIs Schema by Open API
> 3.0.
> 
> > Do we have a sample/mock API where we can show that the Action and
> Microversions can be declared to reflect reality and it can actually work
> with the generated code?
> Yeah, you can copy this yaml [1] into editor [2] to generate server or
> client codes or try it out.
> We can do more demos later.
> 
> [1]
> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml
> [2] https://editor.swagger.io
> 
> Best Regards,
> Edison Xiang

How does this proposal relate to the work that has already been
done to build the API guide
https://developer.openstack.org/api-guide/quick-start/ documentation?

Doug

> 
> On Wed, Aug 29, 2018 at 6:31 PM Davanum Srinivas  wrote:
> 
> > Edison,
> >
> > This is definitely a step in the right direction if we can pull it off.
> >
> > Given the previous experiences and the current situation of how and where
> > we store the information currently and how we generate the website for the
> > API(s), can you please outline
> > - what would be the impact to projects?
> > - what steps they would have to take?
> >
> > Also, the whole point of having these definitions is that the generated
> > code works. Do we have a sample/mock API where we can show that the Action
> > and Microversions can be declared to reflect reality and it can actually
> > work with the generated code?
> >
> > Thanks,
> > Dims
> >
> > On Wed, Aug 29, 2018 at 2:37 AM Edison Xiang 
> > wrote:
> >
> >> Hi team,
> >>
> >> As we know, Open API 3.0 was released on July, 2017, it is about one year
> >> ago.
> >> Open API 3.0 support some new features like anyof, oneof and allof than
> >> Open API 2.0(Swagger 2.0).
> >> Now OpenStack projects do not support Open API.
> >> Also I found some old emails in the Mail List about supporting Open API
> >> 2.0 in OpenStack.
> >>
> >> Some limitations are mentioned in the Mail List for OpenStack API:
> >> 1. The POST */action APIs.
> >> These APIs are exist in lots of projects like nova, cinder.
> >> These APIs have the same URI but the responses will be different when
> >> the request is different.
> >> 2. Micro versions.
> >> These are controller via headers, which are sometimes used to
> >> describe behavioral changes in an API, not just request/response schema
> >> changes.
> >>
> >> About the first limitation, we can find the solution in the Open API 3.0.
> >> The example [2] shows that we can define different request/response in
> >> the same URI by anyof feature in Open API 3.0.
> >>
> >> About the micro versions problem, I think it is not a limitation related
> >> a special API Standard.
> >> We can list all micro versions API schema files in one directory like
> >> nova/V2,
> >> or we can list the schema changes between micro versions as tempest
> >> project did [3].
> >>
> >> Based on Open API 3.0, it can bring lots of benefits for OpenStack
> >> Community and does not impact the current features the  Community has.
> >> For example, we can automatically generate API documents, different
> >> language Clients(SDK) maybe for different micro versions,
> >> and generate cloud tool adapters for OpenStack, like ansible module,
> >> terraform providers and so on.
> >> Also we can make an API UI to provide an online and visible API search,
> >> API Calling for every OpenStack API.
> >> 3rd party developers can also do some self-defined development.
> >>
> >> [1] https://github.com/OAI/OpenAPI-Specification
> >> [2]
> >> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
> >> [3]
> >> https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute
> >>
> >> Best Regards,
> >> Edison Xiang
> >>
> >> __
> >> 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
> >>
> >
> >
> > --
> > Davanum Srinivas :: https://twitter.com/dims
> > __
> > 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] [api] Open API 3.0 for OpenStack API

[Edison Xiang]

Hey dims,

Thanks your reply. Your suggestion is very important.

> what would be the impact to projects?
> what steps they would have to take?

We can launch a project to publish OpenStack Projects APIs Schema for users
and  developers.
But now OpenStack Projects have no APIs Schema definition.
Open API will not impact OpenStack Projects features they have,
but we need some volunteers to define every project APIs Schema by Open API
3.0.

> Do we have a sample/mock API where we can show that the Action and
Microversions can be declared to reflect reality and it can actually work
with the generated code?
Yeah, you can copy this yaml [1] into editor [2] to generate server or
client codes or try it out.
We can do more demos later.

[1]
https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml
[2] https://editor.swagger.io

Best Regards,
Edison Xiang

On Wed, Aug 29, 2018 at 6:31 PM Davanum Srinivas  wrote:

> Edison,
>
> This is definitely a step in the right direction if we can pull it off.
>
> Given the previous experiences and the current situation of how and where
> we store the information currently and how we generate the website for the
> API(s), can you please outline
> - what would be the impact to projects?
> - what steps they would have to take?
>
> Also, the whole point of having these definitions is that the generated
> code works. Do we have a sample/mock API where we can show that the Action
> and Microversions can be declared to reflect reality and it can actually
> work with the generated code?
>
> Thanks,
> Dims
>
> On Wed, Aug 29, 2018 at 2:37 AM Edison Xiang 
> wrote:
>
>> Hi team,
>>
>> As we know, Open API 3.0 was released on July, 2017, it is about one year
>> ago.
>> Open API 3.0 support some new features like anyof, oneof and allof than
>> Open API 2.0(Swagger 2.0).
>> Now OpenStack projects do not support Open API.
>> Also I found some old emails in the Mail List about supporting Open API
>> 2.0 in OpenStack.
>>
>> Some limitations are mentioned in the Mail List for OpenStack API:
>> 1. The POST */action APIs.
>> These APIs are exist in lots of projects like nova, cinder.
>> These APIs have the same URI but the responses will be different when
>> the request is different.
>> 2. Micro versions.
>> These are controller via headers, which are sometimes used to
>> describe behavioral changes in an API, not just request/response schema
>> changes.
>>
>> About the first limitation, we can find the solution in the Open API 3.0.
>> The example [2] shows that we can define different request/response in
>> the same URI by anyof feature in Open API 3.0.
>>
>> About the micro versions problem, I think it is not a limitation related
>> a special API Standard.
>> We can list all micro versions API schema files in one directory like
>> nova/V2,
>> or we can list the schema changes between micro versions as tempest
>> project did [3].
>>
>> Based on Open API 3.0, it can bring lots of benefits for OpenStack
>> Community and does not impact the current features the  Community has.
>> For example, we can automatically generate API documents, different
>> language Clients(SDK) maybe for different micro versions,
>> and generate cloud tool adapters for OpenStack, like ansible module,
>> terraform providers and so on.
>> Also we can make an API UI to provide an online and visible API search,
>> API Calling for every OpenStack API.
>> 3rd party developers can also do some self-defined development.
>>
>> [1] https://github.com/OAI/OpenAPI-Specification
>> [2]
>> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
>> [3]
>> https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute
>>
>> Best Regards,
>> Edison Xiang
>>
>> __
>> 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
>>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
> __
> 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] [api] Open API 3.0 for OpenStack API

[Edison Xiang]

Hi Jay,

Thanks your reply.

As we know, we can automatically generate API Documents, different language
of Clients(SDK),
cloud tool adapters for OpenStack based on Open API 3.0 Schema.

About the other self-defined development for 3rd party developers,
based on the Open API 3.0 schema, developers can develop UI for API online
search, API online calling.
or directly call OpenStack API that it does not need Clients(SDK),
or self-defined API Documents and so on.
Since there is a good ecosystem around Open API,
developers can do whatever they want based on Open API 3.0 schema.

Best Regards,
Edison Xiang

On Wed, Aug 29, 2018 at 8:12 PM Jay Pipes  wrote:

> On 08/29/2018 02:36 AM, Edison Xiang wrote:
> > Based on Open API 3.0, it can bring lots of benefits for OpenStack
> > Community and does not impact the current features the Community has.
> 
> > 3rd party developers can also do some self-defined development.
>
> Hi Edison,
>
> Would you mind expanding on what you are referring to with the above
> line about 3rd party developers doing self-defined development?
>
> Thanks!
> -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] [api] Open API 3.0 for OpenStack API

[Edison Xiang]

Hi Ed Leafe,

Thanks your reply.
Open API defines a standard interface description for REST APIs.
Open API 3.0 can make a description(schema) for current OpenStack REST API.
It will not change current OpenStack API.
I am not a GraphQL expert. I look up something about GraphQL.
In my understanding, GraphQL will get current OpenAPI together and provide
another APIs based on Relay,
and Open API is used to describe REST APIs and GraphQL is used to describe
Relay APIs.

Best Regards,
Edison Xiang

On Wed, Aug 29, 2018 at 9:33 PM Ed Leafe  wrote:

> On Aug 29, 2018, at 1:36 AM, Edison Xiang  wrote:
> >
> > As we know, Open API 3.0 was released on July, 2017, it is about one
> year ago.
> > Open API 3.0 support some new features like anyof, oneof and allof than
> Open API 2.0(Swagger 2.0).
> > Now OpenStack projects do not support Open API.
> > Also I found some old emails in the Mail List about supporting Open API
> 2.0 in OpenStack.
>
> There is currently an effort by some developers to investigate the
> possibility of using GraphQL with OpenStack APIs. What would Open API 3.0
> provide that GraphQL would not? I’m asking because I don’t know enough
> about Open API to compare them.
>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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] [api] Open API 3.0 for OpenStack API

[Ed Leafe]

On Aug 29, 2018, at 1:36 AM, Edison Xiang  wrote:
> 
> As we know, Open API 3.0 was released on July, 2017, it is about one year ago.
> Open API 3.0 support some new features like anyof, oneof and allof than Open 
> API 2.0(Swagger 2.0).
> Now OpenStack projects do not support Open API.
> Also I found some old emails in the Mail List about supporting Open API 2.0 
> in OpenStack.

There is currently an effort by some developers to investigate the possibility 
of using GraphQL with OpenStack APIs. What would Open API 3.0 provide that 
GraphQL would not? I’m asking because I don’t know enough about Open API to 
compare them.


-- Ed Leafe






__
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] [api] Open API 3.0 for OpenStack API

[Jay Pipes]

On 08/29/2018 02:36 AM, Edison Xiang wrote:
Based on Open API 3.0, it can bring lots of benefits for OpenStack 
Community and does not impact the current features the Community has.



3rd party developers can also do some self-defined development.


Hi Edison,

Would you mind expanding on what you are referring to with the above 
line about 3rd party developers doing self-defined development?


Thanks!
-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] [api] Open API 3.0 for OpenStack API

[Davanum Srinivas]

Edison,

This is definitely a step in the right direction if we can pull it off.

Given the previous experiences and the current situation of how and where
we store the information currently and how we generate the website for the
API(s), can you please outline
- what would be the impact to projects?
- what steps they would have to take?

Also, the whole point of having these definitions is that the generated
code works. Do we have a sample/mock API where we can show that the Action
and Microversions can be declared to reflect reality and it can actually
work with the generated code?

Thanks,
Dims

On Wed, Aug 29, 2018 at 2:37 AM Edison Xiang  wrote:

> Hi team,
>
> As we know, Open API 3.0 was released on July, 2017, it is about one year
> ago.
> Open API 3.0 support some new features like anyof, oneof and allof than
> Open API 2.0(Swagger 2.0).
> Now OpenStack projects do not support Open API.
> Also I found some old emails in the Mail List about supporting Open API
> 2.0 in OpenStack.
>
> Some limitations are mentioned in the Mail List for OpenStack API:
> 1. The POST */action APIs.
> These APIs are exist in lots of projects like nova, cinder.
> These APIs have the same URI but the responses will be different when
> the request is different.
> 2. Micro versions.
> These are controller via headers, which are sometimes used to describe
> behavioral changes in an API, not just request/response schema changes.
>
> About the first limitation, we can find the solution in the Open API 3.0.
> The example [2] shows that we can define different request/response in the
> same URI by anyof feature in Open API 3.0.
>
> About the micro versions problem, I think it is not a limitation related a
> special API Standard.
> We can list all micro versions API schema files in one directory like
> nova/V2,
> or we can list the schema changes between micro versions as tempest
> project did [3].
>
> Based on Open API 3.0, it can bring lots of benefits for OpenStack
> Community and does not impact the current features the  Community has.
> For example, we can automatically generate API documents, different
> language Clients(SDK) maybe for different micro versions,
> and generate cloud tool adapters for OpenStack, like ansible module,
> terraform providers and so on.
> Also we can make an API UI to provide an online and visible API search,
> API Calling for every OpenStack API.
> 3rd party developers can also do some self-defined development.
>
> [1] https://github.com/OAI/OpenAPI-Specification
> [2]
> https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
> [3]
> https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute
>
> Best Regards,
> Edison Xiang
>
> __
> 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
>


-- 
Davanum Srinivas :: https://twitter.com/dims
__
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-dev] [api] Open API 3.0 for OpenStack API

[Edison Xiang]

Hi team,

As we know, Open API 3.0 was released on July, 2017, it is about one year
ago.
Open API 3.0 support some new features like anyof, oneof and allof than
Open API 2.0(Swagger 2.0).
Now OpenStack projects do not support Open API.
Also I found some old emails in the Mail List about supporting Open API 2.0
in OpenStack.

Some limitations are mentioned in the Mail List for OpenStack API:
1. The POST */action APIs.
These APIs are exist in lots of projects like nova, cinder.
These APIs have the same URI but the responses will be different when
the request is different.
2. Micro versions.
These are controller via headers, which are sometimes used to describe
behavioral changes in an API, not just request/response schema changes.

About the first limitation, we can find the solution in the Open API 3.0.
The example [2] shows that we can define different request/response in the
same URI by anyof feature in Open API 3.0.

About the micro versions problem, I think it is not a limitation related a
special API Standard.
We can list all micro versions API schema files in one directory like
nova/V2,
or we can list the schema changes between micro versions as tempest project
did [3].

Based on Open API 3.0, it can bring lots of benefits for OpenStack
Community and does not impact the current features the  Community has.
For example, we can automatically generate API documents, different
language Clients(SDK) maybe for different micro versions,
and generate cloud tool adapters for OpenStack, like ansible module,
terraform providers and so on.
Also we can make an API UI to provide an online and visible API search, API
Calling for every OpenStack API.
3rd party developers can also do some self-defined development.

[1] https://github.com/OAI/OpenAPI-Specification
[2]
https://github.com/edisonxiang/OpenAPI-Specification/blob/master/examples/v3.0/petstore.yaml#L94-L109
[3]
https://github.com/openstack/tempest/tree/master/tempest/lib/api_schema/response/compute

Best Regards,
Edison Xiang
__
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] [api] [cinder] backup restore in api v2

[Jay S Bryant]

On 8/15/2018 8:00 AM, Sean McGinnis wrote:

On Wed, Aug 15, 2018 at 07:52:47AM -0500, Sean McGinnis wrote:

On Wed, Aug 15, 2018 at 09:32:45AM +0200, Artem Goncharov wrote:

Hi all,

I have recently faced an interesting question: is there no backup restore
functionality in block-storage api v2? There is possibility to create
backup, but not to restore it according to
https://developer.openstack.org/api-ref/block-storage/v2/index.html#backups-backups.
Version v3 ref contain restore function. What is also interesting, that
cinderclient contain the restore function for v2. Is this just a v2
documentation bug (what I assume) or was it an unsupported function in v2?

Thanks,
Artem

Thanks for pointing that out Artem. That does appear to be a documentation bug.
The backup API has not changed, so v2 and v3 should be identical in that
regard. We will need to update our docs to reflect that.

Sean

Ah, we just did a really good job of hiding it:

https://developer.openstack.org/api-ref/block-storage/v2/index.html#restore-backup

I see the formatting for that document is off so that it actually appears as a
section under the delete documentation. I will get that fixed.

Artem and Sean,

Thanks for finding that and fixing it.

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



__
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] [api] [cinder] backup restore in api v2

[Sean McGinnis]

On Wed, Aug 15, 2018 at 07:52:47AM -0500, Sean McGinnis wrote:
> On Wed, Aug 15, 2018 at 09:32:45AM +0200, Artem Goncharov wrote:
> > Hi all,
> > 
> > I have recently faced an interesting question: is there no backup restore
> > functionality in block-storage api v2? There is possibility to create
> > backup, but not to restore it according to
> > https://developer.openstack.org/api-ref/block-storage/v2/index.html#backups-backups.
> > Version v3 ref contain restore function. What is also interesting, that
> > cinderclient contain the restore function for v2. Is this just a v2
> > documentation bug (what I assume) or was it an unsupported function in v2?
> > 
> > Thanks,
> > Artem
> 
> Thanks for pointing that out Artem. That does appear to be a documentation 
> bug.
> The backup API has not changed, so v2 and v3 should be identical in that
> regard. We will need to update our docs to reflect that.
> 
> Sean

Ah, we just did a really good job of hiding it:

https://developer.openstack.org/api-ref/block-storage/v2/index.html#restore-backup

I see the formatting for that document is off so that it actually appears as a
section under the delete documentation. I will get that fixed.

> 
> __
> 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] [api] [cinder] backup restore in api v2

[Sean McGinnis]

On Wed, Aug 15, 2018 at 09:32:45AM +0200, Artem Goncharov wrote:
> Hi all,
> 
> I have recently faced an interesting question: is there no backup restore
> functionality in block-storage api v2? There is possibility to create
> backup, but not to restore it according to
> https://developer.openstack.org/api-ref/block-storage/v2/index.html#backups-backups.
> Version v3 ref contain restore function. What is also interesting, that
> cinderclient contain the restore function for v2. Is this just a v2
> documentation bug (what I assume) or was it an unsupported function in v2?
> 
> Thanks,
> Artem

Thanks for pointing that out Artem. That does appear to be a documentation bug.
The backup API has not changed, so v2 and v3 should be identical in that
regard. We will need to update our docs to reflect that.

Sean

__
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-dev] [api] [cinder] backup restore in api v2

[Artem Goncharov]

Hi all,

I have recently faced an interesting question: is there no backup restore
functionality in block-storage api v2? There is possibility to create
backup, but not to restore it according to
https://developer.openstack.org/api-ref/block-storage/v2/index.html#backups-backups.
Version v3 ref contain restore function. What is also interesting, that
cinderclient contain the restore function for v2. Is this just a v2
documentation bug (what I assume) or was it an unsupported function in v2?

Thanks,
Artem
__
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-dev] [api] notes from api-sig forum meeting on graphql experiment

[Michael McCune]

hi everybody,

i have added my notes to the etherpad[1] from summit.

briefly, we had a great meeting about creating a graphql experiment in
openstack and i tried to capture some of the questions and comments
that flew back and forth.

there seems to be a good consensus that a proof of concept will be
created on the neutron server, most likely in an experimental feature
branch. Gilles Dubreuil has volunteered to lead this effort (thank you
Gilles!), hopefully with some help from a few neutron savy folks ;)

it is still very early in this experiment, but i think there was a
good feeling that if this works it could create some great
opportunities for improvement across the openstack ecosystem. i really
hope it does!

peace o/


[1]: https://etherpad.openstack.org/p/YVR18-API-SIG-forum

__
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] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

Yeah, when I said foundation I’m talking about the community.

@Gilles, count me on if you need someone to work with.
Le sam. 5 mai 2018 à 17:20, Jeremy Stanley  a écrit :

> On 2018-05-04 23:42:59 + (+), Flint WALRUS wrote:
> [...]
> > what operators are expecting the foundation to do with such
> > challenges.
> [...]
>
> If by "the foundation" you mean the OpenStack Foundation then this
> isn't really their remit. You need invested members of the community
> at large to join you in taking up this challenge (as you've
> correctly noted elsewhere). While the foundation and other
> leadership bodies may occasionally find successful ways to steer the
> project as a whole, the community is made up of individual entities
> (contributors and in many cases the organizations who employ them)
> who have their own goals and set their own priorities.
> --
> Jeremy Stanley
> __
> 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] [api] REST limitations and GraghQL inception?

[Jeremy Stanley]

On 2018-05-04 23:42:59 + (+), Flint WALRUS wrote:
[...]
> what operators are expecting the foundation to do with such
> challenges.
[...]

If by "the foundation" you mean the OpenStack Foundation then this
isn't really their remit. You need invested members of the community
at large to join you in taking up this challenge (as you've
correctly noted elsewhere). While the foundation and other
leadership bodies may occasionally find successful ways to steer the
project as a whole, the community is made up of individual entities
(contributors and in many cases the organizations who employ them)
who have their own goals and set their own priorities.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

 >
>> Even without using GraphQL, Making the api more
declarative anyway,
>> has advantages.
>
> +1
>
>> Thanks,
>> Kevin
>> 
>> From: Jay Pipes [jaypi...@gmail.com
<mailto:jaypi...@gmail.com>]
>> Sent: Thursday, May 03, 2018 10:50 AM
>> To: openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [api] REST limitations and
GraghQL
>> inception?
>>
>> On 05/03/2018 12:57 PM, Ed Leafe wrote:
>>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil
<gdubr...@redhat.com <mailto:gdubr...@redhat.com>>
>>> wrote:
>>>>> • We should get a common consensus before all projects
start to
>>>>> implement it.
>>>> This is going to be raised during the API SIG weekly
meeting later
>>>> this week.
>>>> API developers (at least one) from every project are
strongly
>>>> welcomed to participate.
>>>> I suppose it makes sense for the API SIG to be the place
to discuss
>>>> it, at least initially.
>>> It was indeed discussed, and we think that it would be a
worthwhile
>>> experiment. But it would be a difficult, if not
impossible, proposal
>>> to have adopted OpenStack-wide without some data to back
it up. So
>>> what we thought would be a good starting point would be
to have a
>>> group of individuals interested in GraphQL form an
informal team and
>>> proceed to wrap one OpenStack API as a proof-of-concept.
Monty
>>> Taylor suggested Neutron as an excellent candidate, as
its API
>>> exposes things at an individual table level, requiring
the client to
>>> join that information to get the answers they need.
>>>
>>> Once that is done, we could examine the results, and use
them as the
>>> basis for proceeding with something more comprehensive.
Does that
>>> sound like a good approach to (all of) you?
>> Did anyone bring up the differences between control plane
APIs and data
>> APIs and the applicability of GraphQL to the latter and
not the former?
>>
>> For example, a control plane API to reboot a server
instance looks like
>> this:
>>
>> POST /servers/{uuid}/action
>> {
>>   "reboot" : {
>>   "type" : "HARD"
>>   }
>> }
>>
>> how does that map to GraphQL? Via GraphQL's "mutations"
[0]? That
>> doesn't really work since the server object isn't being
mutated. I mean,
>> the state of the server will *eventually* be mutated when
the reboot
>> action starts kicking in (the above is an async operation
returning a
>> 202 Accepted). But the act of hitting POST
/servers/{uuid}/action
>> doesn't actually mutate the server's state.
>>
>> This is just one example of where GraphQL doesn't
necessarily map well
>> to control plane APIs that happen to be built on top of
REST/HTTP [1]
>>
>> Bottom line for me would be what is the perceivable
benefit that all of
>> our users would receive given the (very costly) overhaul
of our APIs
>> that would likely be required.
>>
>> Best,
>> -jay
>>
>> [0] http://graphql.org/learn/queries/#mutations
>> [1] One could argue (and I have in the past) that POST
>> /servers/{uuid}/action isn't a RESTful interface at all...
>>
>>

__

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

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

I will not attend the vancouver summit but I’ll try to attend the berlin
one as it’s closer to me.

However I’ll be happy to join the conversation and give a hand, especially
if you need an operational point of view as our Openstack usage is
constantly growing within an heterogeneous environment ranging from a
grizzly cluster (deprecating it this year) to a shiny Queens one on
multiple geographic area.

I think our setup gives us a really good point of view of what are the
Openstack PITA and what operators are expecting the foundation to do with
such challenges.
Le sam. 5 mai 2018 à 01:18, Gilles Dubreuil <gdubr...@redhat.com> a écrit :

> Right, let's announce the Proof of Concept project as of Neutron, invite
> anyone interested and start it.
>
> There is an API SIG BoF at Vancouver, where we will announce it too. And
> for everyone who can attend, to be welcome to discuss it:
>
> https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session
>
> Yeah, Graphene is the only one listed by GraphQL organization for Python:
> http://graphql.org/code/#python.
>
> I think we should take this discussion on the coming project thread.
>
> Thank you everyone and see you there.
>
> Cheers,
> Gilles
>
> On 04/05/18 23:16, Flint WALRUS wrote:
>
> As clarify by Gilles and Kevin we absolutely can  get GraphQL with the
> control plan API and the workers api.
>
> Ok, how do start to work on that? What’s the next step?
>
> Which server library do we want to use?
> I personally use graphene with python as it is the library listed by the
> official GraphQL website. I don’t even know if there is another library
> available indeed.
>
> Are we ok to try to use neutron as a PoC service?
>
> Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil <gdubr...@redhat.com> a
> écrit :
>
>> Actually Mutations fields are only data to be displayed, if needed, by
>> the response.
>> The data changes comes with the parameters.
>> So the correct mutation syntax is:
>>
>> mutation rebootServer {
>>updateServer(id: ) {
>>  reboot(type: "HARD")
>>}
>> }
>>
>> Also the latter example would be a "data API" equivalent using CRUD
>> function like "updateServer"
>>
>> And the following example would be a "plane API" equivalent approach
>> with an action function:
>>
>> mutation hardReboot {
>>rebootServer(id: , type: "HARD")
>> }
>>
>> Sorry for the initial confusion but I think this is important because
>> GraphQL schema helps clarify data and the operations.
>>
>>
>> On 04/05/18 13:20, Gilles Dubreuil wrote:
>> >
>> > On 04/05/18 05:34, Fox, Kevin M wrote:
>> >> k8s does that I think by separating desired state from actual state
>> >> and working to bring the two inline. the same could (maybe even
>> >> should) be done to openstack. But your right, that is not a small
>> >> amount of work.
>> >
>> > K8s makes perfect sense to follow declarative approach.
>> >
>> > That said a mutation following control plane API action semantic could
>> > be very similar:
>> >
>> > mutation rebootServer {
>> >   Server(id: ) {
>> > reboot: {
>> >   type: "HARD"
>> > }
>> >   }
>> > }
>> >
>> >
>> > "rebootServer" being an alias to name the request.
>> >
>> >
>> >> Even without using GraphQL, Making the api more declarative anyway,
>> >> has advantages.
>> >
>> > +1
>> >
>> >> Thanks,
>> >> Kevin
>> >> 
>> >> From: Jay Pipes [jaypi...@gmail.com]
>> >> Sent: Thursday, May 03, 2018 10:50 AM
>> >> To: openstack-dev@lists.openstack.org
>> >> Subject: Re: [openstack-dev] [api] REST limitations and GraghQL
>> >> inception?
>> >>
>> >> On 05/03/2018 12:57 PM, Ed Leafe wrote:
>> >>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubr...@redhat.com>
>> >>> wrote:
>> >>>>> • We should get a common consensus before all projects start to
>> >>>>> implement it.
>> >>>> This is going to be raised during the API SIG weekly meeting later
>> >>>> this week.
>> >>>> API developers (at least one) from every project are strongly
>> >>>> welcomed to participate.
>> >>>> I suppose it makes 

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

Right, let's announce the Proof of Concept project as of Neutron, invite 
anyone interested and start it.


There is an API SIG BoF at Vancouver, where we will announce it too. And 
for everyone who can attend, to be welcome to discuss it:

https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session

Yeah, Graphene is the only one listed by GraphQL organization for 
Python: http://graphql.org/code/#python.


I think we should take this discussion on the coming project thread.

Thank you everyone and see you there.

Cheers,
Gilles


On 04/05/18 23:16, Flint WALRUS wrote:
As clarify by Gilles and Kevin we absolutely can  get GraphQL with the 
control plan API and the workers api.


Ok, how do start to work on that? What’s the next step?

Which server library do we want to use?
I personally use graphene with python as it is the library listed by 
the official GraphQL website. I don’t even know if there is another 
library available indeed.


Are we ok to try to use neutron as a PoC service?

Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil <gdubr...@redhat.com 
<mailto:gdubr...@redhat.com>> a écrit :


Actually Mutations fields are only data to be displayed, if
needed, by
the response.
The data changes comes with the parameters.
So the correct mutation syntax is:

mutation rebootServer {
   updateServer(id: ) {
 reboot(type: "HARD")
   }
}

Also the latter example would be a "data API" equivalent using CRUD
function like "updateServer"

And the following example would be a "plane API" equivalent approach
with an action function:

mutation hardReboot {
   rebootServer(id: , type: "HARD")
}

Sorry for the initial confusion but I think this is important because
GraphQL schema helps clarify data and the operations.


On 04/05/18 13:20, Gilles Dubreuil wrote:
>
> On 04/05/18 05:34, Fox, Kevin M wrote:
>> k8s does that I think by separating desired state from actual
state
>> and working to bring the two inline. the same could (maybe even
>> should) be done to openstack. But your right, that is not a small
>> amount of work.
>
> K8s makes perfect sense to follow declarative approach.
>
> That said a mutation following control plane API action semantic
could
> be very similar:
>
> mutation rebootServer {
>   Server(id: ) {
>     reboot: {
>   type: "HARD"
>     }
>   }
> }
>
>
> "rebootServer" being an alias to name the request.
>
>
>> Even without using GraphQL, Making the api more declarative
anyway,
>> has advantages.
>
> +1
>
>> Thanks,
>> Kevin
>> 
>> From: Jay Pipes [jaypi...@gmail.com <mailto:jaypi...@gmail.com>]
>> Sent: Thursday, May 03, 2018 10:50 AM
>> To: openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [api] REST limitations and GraghQL
>> inception?
>>
>> On 05/03/2018 12:57 PM, Ed Leafe wrote:
>>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil
<gdubr...@redhat.com <mailto:gdubr...@redhat.com>>
>>> wrote:
>>>>> • We should get a common consensus before all projects start to
>>>>> implement it.
>>>> This is going to be raised during the API SIG weekly meeting
later
>>>> this week.
>>>> API developers (at least one) from every project are strongly
>>>> welcomed to participate.
>>>> I suppose it makes sense for the API SIG to be the place to
discuss
>>>> it, at least initially.
>>> It was indeed discussed, and we think that it would be a
worthwhile
>>> experiment. But it would be a difficult, if not impossible,
proposal
>>> to have adopted OpenStack-wide without some data to back it
up. So
>>> what we thought would be a good starting point would be to have a
>>> group of individuals interested in GraphQL form an informal
team and
>>> proceed to wrap one OpenStack API as a proof-of-concept. Monty
>>> Taylor suggested Neutron as an excellent candidate, as its API
>>> exposes things at an individual table level, requiring the
client to
>>> join that information to get the answers they need.
>>>
>>> Once that is done, we could examine the results, and use them
as the
>>&

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

As clarify by Gilles and Kevin we absolutely can  get GraphQL with the
control plan API and the workers api.

Ok, how do start to work on that? What’s the next step?

Which server library do we want to use?
I personally use graphene with python as it is the library listed by the
official GraphQL website. I don’t even know if there is another library
available indeed.

Are we ok to try to use neutron as a PoC service?

Le ven. 4 mai 2018 à 06:41, Gilles Dubreuil <gdubr...@redhat.com> a écrit :

> Actually Mutations fields are only data to be displayed, if needed, by
> the response.
> The data changes comes with the parameters.
> So the correct mutation syntax is:
>
> mutation rebootServer {
>updateServer(id: ) {
>  reboot(type: "HARD")
>}
> }
>
> Also the latter example would be a "data API" equivalent using CRUD
> function like "updateServer"
>
> And the following example would be a "plane API" equivalent approach
> with an action function:
>
> mutation hardReboot {
>rebootServer(id: , type: "HARD")
> }
>
> Sorry for the initial confusion but I think this is important because
> GraphQL schema helps clarify data and the operations.
>
>
> On 04/05/18 13:20, Gilles Dubreuil wrote:
> >
> > On 04/05/18 05:34, Fox, Kevin M wrote:
> >> k8s does that I think by separating desired state from actual state
> >> and working to bring the two inline. the same could (maybe even
> >> should) be done to openstack. But your right, that is not a small
> >> amount of work.
> >
> > K8s makes perfect sense to follow declarative approach.
> >
> > That said a mutation following control plane API action semantic could
> > be very similar:
> >
> > mutation rebootServer {
> >   Server(id: ) {
> > reboot: {
> >   type: "HARD"
> > }
> >   }
> > }
> >
> >
> > "rebootServer" being an alias to name the request.
> >
> >
> >> Even without using GraphQL, Making the api more declarative anyway,
> >> has advantages.
> >
> > +1
> >
> >> Thanks,
> >> Kevin
> >> 
> >> From: Jay Pipes [jaypi...@gmail.com]
> >> Sent: Thursday, May 03, 2018 10:50 AM
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [api] REST limitations and GraghQL
> >> inception?
> >>
> >> On 05/03/2018 12:57 PM, Ed Leafe wrote:
> >>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubr...@redhat.com>
> >>> wrote:
> >>>>> • We should get a common consensus before all projects start to
> >>>>> implement it.
> >>>> This is going to be raised during the API SIG weekly meeting later
> >>>> this week.
> >>>> API developers (at least one) from every project are strongly
> >>>> welcomed to participate.
> >>>> I suppose it makes sense for the API SIG to be the place to discuss
> >>>> it, at least initially.
> >>> It was indeed discussed, and we think that it would be a worthwhile
> >>> experiment. But it would be a difficult, if not impossible, proposal
> >>> to have adopted OpenStack-wide without some data to back it up. So
> >>> what we thought would be a good starting point would be to have a
> >>> group of individuals interested in GraphQL form an informal team and
> >>> proceed to wrap one OpenStack API as a proof-of-concept. Monty
> >>> Taylor suggested Neutron as an excellent candidate, as its API
> >>> exposes things at an individual table level, requiring the client to
> >>> join that information to get the answers they need.
> >>>
> >>> Once that is done, we could examine the results, and use them as the
> >>> basis for proceeding with something more comprehensive. Does that
> >>> sound like a good approach to (all of) you?
> >> Did anyone bring up the differences between control plane APIs and data
> >> APIs and the applicability of GraphQL to the latter and not the former?
> >>
> >> For example, a control plane API to reboot a server instance looks like
> >> this:
> >>
> >> POST /servers/{uuid}/action
> >> {
> >>   "reboot" : {
> >>   "type" : "HARD"
> >>   }
> >> }
> >>
> >> how does that map to GraphQL? Via GraphQL's "mutations&q

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

Actually Mutations fields are only data to be displayed, if needed, by 
the response.

The data changes comes with the parameters.
So the correct mutation syntax is:

mutation rebootServer {
  updateServer(id: ) {
    reboot(type: "HARD")
  }
}

Also the latter example would be a "data API" equivalent using CRUD 
function like "updateServer"


And the following example would be a "plane API" equivalent approach 
with an action function:


mutation hardReboot {
  rebootServer(id: , type: "HARD")
}

Sorry for the initial confusion but I think this is important because 
GraphQL schema helps clarify data and the operations.



On 04/05/18 13:20, Gilles Dubreuil wrote:


On 04/05/18 05:34, Fox, Kevin M wrote:
k8s does that I think by separating desired state from actual state 
and working to bring the two inline. the same could (maybe even 
should) be done to openstack. But your right, that is not a small 
amount of work.


K8s makes perfect sense to follow declarative approach.

That said a mutation following control plane API action semantic could 
be very similar:


mutation rebootServer {
  Server(id: ) {
    reboot: {
  type: "HARD"
    }
  }
}


"rebootServer" being an alias to name the request.


Even without using GraphQL, Making the api more declarative anyway, 
has advantages.


+1


Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, May 03, 2018 10:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [api] REST limitations and GraghQL 
inception?


On 05/03/2018 12:57 PM, Ed Leafe wrote:
On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubr...@redhat.com> 
wrote:
• We should get a common consensus before all projects start to 
implement it.
This is going to be raised during the API SIG weekly meeting later 
this week.
API developers (at least one) from every project are strongly 
welcomed to participate.
I suppose it makes sense for the API SIG to be the place to discuss 
it, at least initially.
It was indeed discussed, and we think that it would be a worthwhile 
experiment. But it would be a difficult, if not impossible, proposal 
to have adopted OpenStack-wide without some data to back it up. So 
what we thought would be a good starting point would be to have a 
group of individuals interested in GraphQL form an informal team and 
proceed to wrap one OpenStack API as a proof-of-concept. Monty 
Taylor suggested Neutron as an excellent candidate, as its API 
exposes things at an individual table level, requiring the client to 
join that information to get the answers they need.


Once that is done, we could examine the results, and use them as the 
basis for proceeding with something more comprehensive. Does that 
sound like a good approach to (all of) you?

Did anyone bring up the differences between control plane APIs and data
APIs and the applicability of GraphQL to the latter and not the former?

For example, a control plane API to reboot a server instance looks like
this:

POST /servers/{uuid}/action
{
  "reboot" : {
  "type" : "HARD"
  }
}

how does that map to GraphQL? Via GraphQL's "mutations" [0]? That
doesn't really work since the server object isn't being mutated. I mean,
the state of the server will *eventually* be mutated when the reboot
action starts kicking in (the above is an async operation returning a
202 Accepted). But the act of hitting POST /servers/{uuid}/action
doesn't actually mutate the server's state.

This is just one example of where GraphQL doesn't necessarily map well
to control plane APIs that happen to be built on top of REST/HTTP [1]

Bottom line for me would be what is the perceivable benefit that all of
our users would receive given the (very costly) overhaul of our APIs
that would likely be required.

Best,
-jay

[0] http://graphql.org/learn/queries/#mutations
[1] One could argue (and I have in the past) that POST
/servers/{uuid}/action isn't a RESTful interface at all...

__ 


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




--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219


__
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] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

On 04/05/18 05:34, Fox, Kevin M wrote:

k8s does that I think by separating desired state from actual state and working 
to bring the two inline. the same could (maybe even should) be done to 
openstack. But your right, that is not a small amount of work.


K8s makes perfect sense to follow declarative approach.

That said a mutation following control plane API action semantic could 
be very similar:


mutation rebootServer {
  Server(id: ) {
reboot: {
  type: "HARD"
}
  }
}


"rebootServer" being an alias to name the request.



Even without using GraphQL, Making the api more declarative anyway, has 
advantages.


+1


Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, May 03, 2018 10:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [api] REST limitations and GraghQL inception?

On 05/03/2018 12:57 PM, Ed Leafe wrote:

On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubr...@redhat.com> wrote:

• We should get a common consensus before all projects start to implement it.

This is going to be raised during the API SIG weekly meeting later this week.
API developers (at least one) from every project are strongly welcomed to 
participate.
I suppose it makes sense for the API SIG to be the place to discuss it, at 
least initially.

It was indeed discussed, and we think that it would be a worthwhile experiment. 
But it would be a difficult, if not impossible, proposal to have adopted 
OpenStack-wide without some data to back it up. So what we thought would be a 
good starting point would be to have a group of individuals interested in 
GraphQL form an informal team and proceed to wrap one OpenStack API as a 
proof-of-concept. Monty Taylor suggested Neutron as an excellent candidate, as 
its API exposes things at an individual table level, requiring the client to 
join that information to get the answers they need.

Once that is done, we could examine the results, and use them as the basis for 
proceeding with something more comprehensive. Does that sound like a good 
approach to (all of) you?

Did anyone bring up the differences between control plane APIs and data
APIs and the applicability of GraphQL to the latter and not the former?

For example, a control plane API to reboot a server instance looks like
this:

POST /servers/{uuid}/action
{
  "reboot" : {
  "type" : "HARD"
  }
}

how does that map to GraphQL? Via GraphQL's "mutations" [0]? That
doesn't really work since the server object isn't being mutated. I mean,
the state of the server will *eventually* be mutated when the reboot
action starts kicking in (the above is an async operation returning a
202 Accepted). But the act of hitting POST /servers/{uuid}/action
doesn't actually mutate the server's state.

This is just one example of where GraphQL doesn't necessarily map well
to control plane APIs that happen to be built on top of REST/HTTP [1]

Bottom line for me would be what is the perceivable benefit that all of
our users would receive given the (very costly) overhaul of our APIs
that would likely be required.

Best,
-jay

[0] http://graphql.org/learn/queries/#mutations
[1] One could argue (and I have in the past) that POST
/servers/{uuid}/action isn't a RESTful interface at all...

__
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


--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219


__
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] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

+1 for a PoC


On 04/05/18 03:56, Flint WALRUS wrote:

Exactly !
Le jeu. 3 mai 2018 à 19:55, Flint WALRUS > a écrit :


It seems to be a fair way to do it. I do second the Neutron API as
a good candidate.

I’ll be happy to give a hand.

@jay I’ve already sum my points upper, but I could definitely have
better exemples if needed.

I’m operating and dealing with a large (really) Openstack platform
and GraphQL would have tremendous performances impacts for sure.
But you’re right proof have to be made.
Le jeu. 3 mai 2018 à 18:57, Ed Leafe > a écrit :

On May 2, 2018, at 2:40 AM, Gilles Dubreuil
> wrote:
>
>> • We should get a common consensus before all projects
start to implement it.
>
> This is going to be raised during the API SIG weekly meeting
later this week.
> API developers (at least one) from every project are
strongly welcomed to participate.
> I suppose it makes sense for the API SIG to be the place to
discuss it, at least initially.

It was indeed discussed, and we think that it would be a
worthwhile experiment. But it would be a difficult, if not
impossible, proposal to have adopted OpenStack-wide without
some data to back it up. So what we thought would be a good
starting point would be to have a group of individuals
interested in GraphQL form an informal team and proceed to
wrap one OpenStack API as a proof-of-concept. Monty Taylor
suggested Neutron as an excellent candidate, as its API
exposes things at an individual table level, requiring the
client to join that information to get the answers they need.

Once that is done, we could examine the results, and use them
as the basis for proceeding with something more comprehensive.
Does that sound like a good approach to (all of) you?

-- Ed Leafe







__
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



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
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] [api] REST limitations and GraghQL inception?

[Fox, Kevin M]

k8s does that I think by separating desired state from actual state and working 
to bring the two inline. the same could (maybe even should) be done to 
openstack. But your right, that is not a small amount of work.

Even without using GraphQL, Making the api more declarative anyway, has 
advantages.

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Thursday, May 03, 2018 10:50 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [api] REST limitations and GraghQL inception?

On 05/03/2018 12:57 PM, Ed Leafe wrote:
> On May 2, 2018, at 2:40 AM, Gilles Dubreuil <gdubr...@redhat.com> wrote:
>>
>>> • We should get a common consensus before all projects start to implement 
>>> it.
>>
>> This is going to be raised during the API SIG weekly meeting later this week.
>> API developers (at least one) from every project are strongly welcomed to 
>> participate.
>> I suppose it makes sense for the API SIG to be the place to discuss it, at 
>> least initially.
>
> It was indeed discussed, and we think that it would be a worthwhile 
> experiment. But it would be a difficult, if not impossible, proposal to have 
> adopted OpenStack-wide without some data to back it up. So what we thought 
> would be a good starting point would be to have a group of individuals 
> interested in GraphQL form an informal team and proceed to wrap one OpenStack 
> API as a proof-of-concept. Monty Taylor suggested Neutron as an excellent 
> candidate, as its API exposes things at an individual table level, requiring 
> the client to join that information to get the answers they need.
>
> Once that is done, we could examine the results, and use them as the basis 
> for proceeding with something more comprehensive. Does that sound like a good 
> approach to (all of) you?

Did anyone bring up the differences between control plane APIs and data
APIs and the applicability of GraphQL to the latter and not the former?

For example, a control plane API to reboot a server instance looks like
this:

POST /servers/{uuid}/action
{
 "reboot" : {
 "type" : "HARD"
 }
}

how does that map to GraphQL? Via GraphQL's "mutations" [0]? That
doesn't really work since the server object isn't being mutated. I mean,
the state of the server will *eventually* be mutated when the reboot
action starts kicking in (the above is an async operation returning a
202 Accepted). But the act of hitting POST /servers/{uuid}/action
doesn't actually mutate the server's state.

This is just one example of where GraphQL doesn't necessarily map well
to control plane APIs that happen to be built on top of REST/HTTP [1]

Bottom line for me would be what is the perceivable benefit that all of
our users would receive given the (very costly) overhaul of our APIs
that would likely be required.

Best,
-jay

[0] http://graphql.org/learn/queries/#mutations
[1] One could argue (and I have in the past) that POST
/servers/{uuid}/action isn't a RESTful interface at all...

__
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] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

It seems to be a fair way to do it. I do second the Neutron API as a good
candidate.

I’ll be happy to give a hand.

@jay I’ve already sum my points upper, but I could definitely have better
exemples if needed.

I’m operating and dealing with a large (really) Openstack platform and
GraphQL would have tremendous performances impacts for sure. But you’re
right proof have to be made.
Le jeu. 3 mai 2018 à 18:57, Ed Leafe  a écrit :

> On May 2, 2018, at 2:40 AM, Gilles Dubreuil  wrote:
> >
> >> • We should get a common consensus before all projects start to
> implement it.
> >
> > This is going to be raised during the API SIG weekly meeting later this
> week.
> > API developers (at least one) from every project are strongly welcomed
> to participate.
> > I suppose it makes sense for the API SIG to be the place to discuss it,
> at least initially.
>
> It was indeed discussed, and we think that it would be a worthwhile
> experiment. But it would be a difficult, if not impossible, proposal to
> have adopted OpenStack-wide without some data to back it up. So what we
> thought would be a good starting point would be to have a group of
> individuals interested in GraphQL form an informal team and proceed to wrap
> one OpenStack API as a proof-of-concept. Monty Taylor suggested Neutron as
> an excellent candidate, as its API exposes things at an individual table
> level, requiring the client to join that information to get the answers
> they need.
>
> Once that is done, we could examine the results, and use them as the basis
> for proceeding with something more comprehensive. Does that sound like a
> good approach to (all of) you?
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

Exactly !
Le jeu. 3 mai 2018 à 19:55, Flint WALRUS  a écrit :

> It seems to be a fair way to do it. I do second the Neutron API as a good
> candidate.
>
> I’ll be happy to give a hand.
>
> @jay I’ve already sum my points upper, but I could definitely have better
> exemples if needed.
>
> I’m operating and dealing with a large (really) Openstack platform and
> GraphQL would have tremendous performances impacts for sure. But you’re
> right proof have to be made.
> Le jeu. 3 mai 2018 à 18:57, Ed Leafe  a écrit :
>
>> On May 2, 2018, at 2:40 AM, Gilles Dubreuil  wrote:
>> >
>> >> • We should get a common consensus before all projects start to
>> implement it.
>> >
>> > This is going to be raised during the API SIG weekly meeting later this
>> week.
>> > API developers (at least one) from every project are strongly welcomed
>> to participate.
>> > I suppose it makes sense for the API SIG to be the place to discuss it,
>> at least initially.
>>
>> It was indeed discussed, and we think that it would be a worthwhile
>> experiment. But it would be a difficult, if not impossible, proposal to
>> have adopted OpenStack-wide without some data to back it up. So what we
>> thought would be a good starting point would be to have a group of
>> individuals interested in GraphQL form an informal team and proceed to wrap
>> one OpenStack API as a proof-of-concept. Monty Taylor suggested Neutron as
>> an excellent candidate, as its API exposes things at an individual table
>> level, requiring the client to join that information to get the answers
>> they need.
>>
>> Once that is done, we could examine the results, and use them as the
>> basis for proceeding with something more comprehensive. Does that sound
>> like a good approach to (all of) you?
>>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>>
>> __
>> 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] [api] REST limitations and GraghQL inception?

[Ed Leafe]

On May 3, 2018, at 12:50 PM, Jay Pipes  wrote:
> 
> Bottom line for me would be what is the perceivable benefit that all of our 
> users would receive given the (very costly) overhaul of our APIs that would 
> likely be required.

That was our thinking: no one would agree to such an effort without first 
demonstrating some tangible results. Hence the idea for an experiment with just 
a single service, done by those interested in seeing it happen. If GraphQL can 
do what they imagine it could do, then they would be able to demonstrate the 
benefit that you (and everyone else) would want to see.


-- Ed Leafe






__
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] [api] REST limitations and GraghQL inception?

[Jay Pipes]

On 05/03/2018 12:57 PM, Ed Leafe wrote:

On May 2, 2018, at 2:40 AM, Gilles Dubreuil  wrote:



• We should get a common consensus before all projects start to implement it.


This is going to be raised during the API SIG weekly meeting later this week.
API developers (at least one) from every project are strongly welcomed to 
participate.
I suppose it makes sense for the API SIG to be the place to discuss it, at 
least initially.


It was indeed discussed, and we think that it would be a worthwhile experiment. 
But it would be a difficult, if not impossible, proposal to have adopted 
OpenStack-wide without some data to back it up. So what we thought would be a 
good starting point would be to have a group of individuals interested in 
GraphQL form an informal team and proceed to wrap one OpenStack API as a 
proof-of-concept. Monty Taylor suggested Neutron as an excellent candidate, as 
its API exposes things at an individual table level, requiring the client to 
join that information to get the answers they need.

Once that is done, we could examine the results, and use them as the basis for 
proceeding with something more comprehensive. Does that sound like a good 
approach to (all of) you?


Did anyone bring up the differences between control plane APIs and data 
APIs and the applicability of GraphQL to the latter and not the former?


For example, a control plane API to reboot a server instance looks like 
this:


POST /servers/{uuid}/action
{
"reboot" : {
"type" : "HARD"
}
}

how does that map to GraphQL? Via GraphQL's "mutations" [0]? That 
doesn't really work since the server object isn't being mutated. I mean, 
the state of the server will *eventually* be mutated when the reboot 
action starts kicking in (the above is an async operation returning a 
202 Accepted). But the act of hitting POST /servers/{uuid}/action 
doesn't actually mutate the server's state.


This is just one example of where GraphQL doesn't necessarily map well 
to control plane APIs that happen to be built on top of REST/HTTP [1]


Bottom line for me would be what is the perceivable benefit that all of 
our users would receive given the (very costly) overhaul of our APIs 
that would likely be required.


Best,
-jay

[0] http://graphql.org/learn/queries/#mutations
[1] One could argue (and I have in the past) that POST 
/servers/{uuid}/action isn't a RESTful interface at all...


__
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] [api] REST limitations and GraghQL inception?

[Ed Leafe]

On May 2, 2018, at 2:40 AM, Gilles Dubreuil  wrote:
> 
>> • We should get a common consensus before all projects start to implement it.
> 
> This is going to be raised during the API SIG weekly meeting later this week.
> API developers (at least one) from every project are strongly welcomed to 
> participate.
> I suppose it makes sense for the API SIG to be the place to discuss it, at 
> least initially. 

It was indeed discussed, and we think that it would be a worthwhile experiment. 
But it would be a difficult, if not impossible, proposal to have adopted 
OpenStack-wide without some data to back it up. So what we thought would be a 
good starting point would be to have a group of individuals interested in 
GraphQL form an informal team and proceed to wrap one OpenStack API as a 
proof-of-concept. Monty Taylor suggested Neutron as an excellent candidate, as 
its API exposes things at an individual table level, requiring the client to 
join that information to get the answers they need.

Once that is done, we could examine the results, and use them as the basis for 
proceeding with something more comprehensive. Does that sound like a good 
approach to (all of) you?

-- Ed Leafe






__
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] [api] REST limitations and GraghQL inception?

[Flint WALRUS]

Hi Gilles, folks,

Nice to read such answers, I’m really thrilled by what could goes out from
this discussion.

One last thing regarding the SDK and Broker part of the discussion.

GraphQL and SDK:

Obviously as you noticed it, I was focused on the python-openstacksdk part
of things even if it apply to the autonomous Openstack4j JAVA SDK or any
other SDK for your favorite language.

I do agree with you, GraphQL being a DSL it should in a long (or maybe not
so long depending the adoption rate ;-) ) run replace the REST part of the
SDK, however, I think the client libraries (at least for the python side of
think) should be enforced by the Openstack foundation/devs as it would
avoid having devs from one project/tool that will join the big tent to use
a different library of its own and so create fragmentation and pitfalls
already mentioned upper on my previous message.

For example, if I let our devs use their own client library for both
GraphQL and workers logic I will end up with at least a dozen of different
libraries per teams and it will be a nightmare to debug, investigate,
maintain etc.

For sure as this is a personal example some could argue that we should
enforce this choice at the company level and not at the solution level, but
if everyone talk the same language its easier to share information, make
consensus around a project, ease the development process by having a clear
and consistent path (Providing a common cookiecutter for all new projects)
and would give us the ability to manage a complete project with the
Openstack client tool such as:

```openstack brick init ```

Here I choose the “brick” term as a keyword in order to avoid namespace
collisions as projects and services are already used for ops side of things.

GraphQL broker:

Ok I see what you means and I honestly love the idea as it’s an elegant way
to split responsibility while being able to scale and efficiently
distribute requests.

I think that’s the implicit idea behind swift-proxy and how (most of)
companies achieve the horizontal scaling with HAProxy as a loadbalancer in
front of classic Openstack WSGI endpoints.

As this is a builtin feature of GraphQL that would allows a way better
service discovery and routing architecture.

Kind regards,
G.

Le mer. 2 mai 2018 à 09:41, Gilles Dubreuil  a écrit :

> I fixed the GraphQL typo (my mistake) in $subject to help with future ML
> searches.
>
> Please see inline too.
>
> On 02/05/18 07:37, Flint WALRUS wrote:
>
> Ok, here are my two cents regarding GraphQL integration within Openstack
> and some thoughts around this topic.
>
> 1°/- Openstack SDK should still exist and should be in my humble opinion a
> critical focus as it allow following benefits for large and medium
> companies :
>
> • It provide a common and clean structure for Openstack developments and
> should be used either by projects or tools willing to integrate Openstack
> as it will then create some sort of standard.
>
> For instance, here in my job we have A LOT (More than 10 000 peoples
> working within around 130 teams) of teams developing over Openstack using
> the SDK as a common shared base layout.
> That allow for teams to easily share and co-develop on projects. Those
> teams are spread around the world and so need to have clean guidelines as
> it avoid them reinventing the wheel, they’re not stuck with someone else
> obscure code created by another persons on the other side of the world or
> within a different timezone.
> Additionally it streamline our support and debug processes.
>
>
> I'm assuming you're talking about the Python SDK (Shade) which would make
> sense because it's the "lingua franca" of all projects.
>
> Nevertheless, for any SDKs/Languages, if adopted then GraphQL is likely to
> replace its REST SDK on the long run. GraphQL is a DSL bypassing a SDK need
> which get replaced with GraphQL client library. Basically the change, not a
> rewrite, is inevitable. But I insist on "the long run" part, initially both
> in parallel one wrapping the other, then progressively the REST content
> moving across to GraphQL.
>
>
> • We should get a common consensus before all projects start to implement
> it.
>
>
>
> This is going to be raised during the API SIG weekly meeting later this
> week.
> API developers (at least one) from every project are strongly welcomed to
> participate.
> I suppose it makes sense for the API SIG to be the place to discuss it, at
> least initially.
>
>
>
> This point is for me the most important one as it will fix flaws we get
> currently with the rest APIs development within Openstack.
>
> First it will avoid a fresh developer to be confused by too many options.
> Honestly, I know we are open etc, but this point really need to be
> addressed as it is the main issue that I face with Openstack advocacy since
> many years now.
>
> Having too many options even if explained within the documentation daunt a
> lot of people to quickly give a hand with projects.
>
> For 

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

[Gilles Dubreuil]

I fixed the GraphQL typo (my mistake) in $subject to help with future ML 
searches.


Please see inline too.


On 02/05/18 07:37, Flint WALRUS wrote:
Ok, here are my two cents regarding GraphQL integration within 
Openstack and some thoughts around this topic.


1°/- Openstack SDK should still exist and should be in my humble 
opinion a critical focus as it allow following benefits for large and 
medium companies :


• It provide a common and clean structure for Openstack developments 
and should be used either by projects or tools willing to integrate 
Openstack as it will then create some sort of standard.


For instance, here in my job we have A LOT (More than 10 000 peoples 
working within around 130 teams) of teams developing over Openstack 
using the SDK as a common shared base layout.
That allow for teams to easily share and co-develop on projects. Those 
teams are spread around the world and so need to have clean guidelines 
as it avoid them reinventing the wheel, they’re not stuck with someone 
else obscure code created by another persons on the other side of the 
world or within a different timezone.

Additionally it streamline our support and debug processes.


I'm assuming you're talking about the Python SDK (Shade) which would 
make sense because it's the "lingua franca" of all projects.


Nevertheless, for any SDKs/Languages, if adopted then GraphQL is likely 
to replace its REST SDK on the long run. GraphQL is a DSL bypassing a 
SDK need which get replaced with GraphQL client library. Basically the 
change, not a rewrite, is inevitable. But I insist on "the long run" 
part, initially both in parallel one wrapping the other, then 
progressively the REST content moving across to GraphQL.




• We should get a common consensus before all projects start to 
implement it.



This is going to be raised during the API SIG weekly meeting later this 
week.
API developers (at least one) from every project are strongly welcomed 
to participate.
I suppose it makes sense for the API SIG to be the place to discuss it, 
at least initially.





This point is for me the most important one as it will fix flaws we 
get currently with the rest APIs development within Openstack.


First it will avoid a fresh developer to be confused by too many 
options. Honestly, I know we are open etc, but this point really need 
to be addressed as it is the main issue that I face with Openstack 
advocacy since many years now.


Having too many options even if explained within the documentation 
daunt a lot of people to quickly give a hand with projects.


For instance I have a workmate that is currently working on an 
internal tool which ask me how should he implement its project REST 
interfaces.


I told him TO NOT use WSME and to stick with what have been done by a 
major project. Unfortunately he choose to copy what have been done by 
Octavia which is actually using... WSME...


GraphQL gives us the opportunity and ability to fix Openstack 
development inconsistencies by providing and enforcing a clean 
guideline regarding which library should be used and in which way.


That would also have the side effect to easy the entry level for a new 
Openstack developer.


I couldn't agree more!



• New architecture opportunities.

For sure that will bring new architecture opportunities, but the 
broker thing is not a good idea as each project should be able to be 
autonomous.


I personally don’t like centralized services as it bring SPOF.

Let’s take the AMQP example. For now most of Openstack deployments use 
a RabbitMQ or broker like system.
Even if each (well at least major vanilla projects) services can (and 
should) use ZeroMQ.
I do myself use RabbitMQ but my last weeks were so much 
debugging/investigation hell that we now plan to have a serious 
benchmark and test of ZMQ.


One thing that I would love to see with GraphQL is a better 
distributed and traceable model.




Exactly and the term broker I used is far from ideal,  I meant it in the 
context of a broker pattern providing distributed API service. GraphQL 
has "stiching" capabilities allowing to forward request to diverse 
GraphQL service, kind of a proxy, ideally such service to be distributed 
itself.


The idea behind is a GraphQL proxy offering a single point of entry for 
OpenStack entire stack and of course leaving complete autonomy to the 
all services.


https://blog.graph.cool/graphql-schema-stitching-explained-schema-delegation-4c6caf468405

Anyway, I’m glad someone started this discussion as I feel it is a 
really important topic that would highly help Openstack on more than 
just interfacing topics.
Le mar. 1 mai 2018 à 05:00, Gilles Dubreuil > a écrit :




On 01/05/18 11:31, Flint WALRUS wrote:

Yes, that’s was indeed the sens of my point.


I was just enforcing it, no worries! ;)




Openstack have to provide both endpoints type for a while for
backward compatibility in order to 

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

Ok, here are my two cents regarding GraphQL integration within Openstack
and some thoughts around this topic.

1°/- Openstack SDK should still exist and should be in my humble opinion a
critical focus as it allow following benefits for large and medium
companies :

• It provide a common and clean structure for Openstack developments and
should be used either by projects or tools willing to integrate Openstack
as it will then create some sort of standard.

For instance, here in my job we have A LOT (More than 10 000 peoples
working within around 130 teams) of teams developing over Openstack using
the SDK as a common shared base layout.
That allow for teams to easily share and co-develop on projects. Those
teams are spread around the world and so need to have clean guidelines as
it avoid them reinventing the wheel, they’re not stuck with someone else
obscure code created by another persons on the other side of the world or
within a different timezone.
Additionally it streamline our support and debug processes.

• We should get a common consensus before all projects start to implement
it.

This point is for me the most important one as it will fix flaws we get
currently with the rest APIs development within Openstack.

First it will avoid a fresh developer to be confused by too many options.
Honestly, I know we are open etc, but this point really need to be
addressed as it is the main issue that I face with Openstack advocacy since
many years now.

Having too many options even if explained within the documentation daunt a
lot of people to quickly give a hand with projects.

For instance I have a workmate that is currently working on an internal
tool which ask me how should he implement its project REST interfaces.

I told him TO NOT use WSME and to stick with what have been done by a major
project. Unfortunately he choose to copy what have been done by Octavia
which is actually using... WSME...

GraphQL gives us the opportunity and ability to fix Openstack development
inconsistencies by providing and enforcing a clean guideline regarding
which library should be used and in which way.

That would also have the side effect to easy the entry level for a new
Openstack developer.

• New architecture opportunities.

For sure that will bring new architecture opportunities, but the broker
thing is not a good idea as each project should be able to be autonomous.

I personally don’t like centralized services as it bring SPOF.

Let’s take the AMQP example. For now most of Openstack deployments use a
RabbitMQ or broker like system.
Even if each (well at least major vanilla projects) services can (and
should) use ZeroMQ.
I do myself use RabbitMQ but my last weeks were so much
debugging/investigation hell that we now plan to have a serious benchmark
and test of ZMQ.

One thing that I would love to see with GraphQL is a better distributed and
traceable model.

Anyway, I’m glad someone started this discussion as I feel it is a really
important topic that would highly help Openstack on more than just
interfacing topics.
Le mar. 1 mai 2018 à 05:00, Gilles Dubreuil  a écrit :

>
>
> On 01/05/18 11:31, Flint WALRUS wrote:
>
> Yes, that’s was indeed the sens of my point.
>
>
> I was just enforcing it, no worries! ;)
>
>
>
> Openstack have to provide both endpoints type for a while for backward
> compatibility in order to smooth the transition.
>
> For instance, that would be a good idea to contact postman devteam once
> GraphQL will start to be integrated as it will allow a lot of ops to keep
> their day to day tools by just having to convert their existing collections
> of handful requests.
>
>
> Shouldn't we have a common consensus before any project start pushing its
> own GraphQL wheel?
>
> Also I wonder how GraphQL could open new architecture avenues for
> OpenStack.
> For example, would that make sense to also have a GraphQL broker linking
> OpenStack services?
>
>
>
>
> Or alternatively to provide a tool with similar features at least.
> Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil  a
> écrit :
>
>>
>>
>> On 30/04/18 20:16, Flint WALRUS wrote:
>>
>> I would very much second that question! Indeed it have been one of my own
>> wondering since many times.
>>
>> Of course GraphQL is not intended to replace REST as is and have to live
>> in parallel
>>
>>
>> Effectively a standard initial architecture is to have GraphQL sitting
>> aside (in parallel) and wrapping REST and along the way develop GrapgQL
>> Schema.
>>
>> It's seems too early to tell but GraphQL being the next step in API
>> evolution it might ultimately replace REST.
>>
>>
>> but it would likely and highly accelerate all requests within heavily
>> loaded environments
>>
>>
>> +1
>>
>>
>> .
>>
>> So +1 for this question.
>> Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil  a
>> écrit :
>>
>>> Hi,
>>>
>>> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
>>> addresses REST limitations.

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 01/05/18 11:31, Flint WALRUS wrote:

Yes, that’s was indeed the sens of my point.


I was just enforcing it, no worries! ;)



Openstack have to provide both endpoints type for a while for backward 
compatibility in order to smooth the transition.


For instance, that would be a good idea to contact postman devteam 
once GraphQL will start to be integrated as it will allow a lot of ops 
to keep their day to day tools by just having to convert their 
existing collections of handful requests.


Shouldn't we have a common consensus before any project start pushing 
its own GraphQL wheel?


Also I wonder how GraphQL could open new architecture avenues for OpenStack.
For example, would that make sense to also have a GraphQL broker linking 
OpenStack services?





Or alternatively to provide a tool with similar features at least.
Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil > a écrit :




On 30/04/18 20:16, Flint WALRUS wrote:

I would very much second that question! Indeed it have been one
of my own wondering since many times.

Of course GraphQL is not intended to replace REST as is and have
to live in parallel 


Effectively a standard initial architecture is to have GraphQL
sitting aside (in parallel) and wrapping REST and along the way
develop GrapgQL Schema.

It's seems too early to tell but GraphQL being the next step in
API evolution it might ultimately replace REST.



but it would likely and highly accelerate all requests within
heavily loaded environments


+1



.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil
> a écrit :

Hi,

Remember Boston's Summit presentation [1] about GraphQL [2]
and how it
addresses REST limitations.
I wonder if any project has been thinking about using
GraphQL. I haven't
find any mention or pointers about it.

GraphQL takes a complete different approach compared to REST.
So we can
finally forget about REST API Description languages
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the
hypermedia
approach which doesn't describe how to use it).

So, once passed the point where 'REST vs GraphQL' is like
comparing SQL
and no-SQL DBMS and therefore have different applications,
there are no
doubt the complexity of most OpenStack projects are good
candidates for
GraphQL.

Besides topics such as efficiency, decoupling, no version
management
need there many other powerful features such as API Schema
out of the
box and better automation down that track.

It looks like the dream of a conduit between API services and
consumers
might have finally come true so we could move-on an worry
about other
things.

So has anyone already starting looking into it?

[1]

https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
[2] http://graphql.org




__
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



-- 
Gilles Dubreuil

Senior Software Engineer - Red Hat - Openstack DFG Integration
Email:gil...@redhat.com 
GitHub/IRC: gildub
Mobile: +61 400 894 219



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
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] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 01/05/18 07:21, Matt Riedemann wrote:

On 4/29/2018 10:53 PM, Gilles Dubreuil wrote:
Remember Boston's Summit presentation [1] about GraphQL [2] and how 
it addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I 
haven't find any mention or pointers about it.


GraphQL takes a complete different approach compared to REST. So we 
can finally forget about REST API Description languages 
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia 
approach which doesn't describe how to use it).


So, once passed the point where 'REST vs GraphQL' is like comparing 
SQL and no-SQL DBMS and therefore have different applications, there 
are no doubt the complexity of most OpenStack projects are good 
candidates for GraphQL.


Besides topics such as efficiency, decoupling, no version management 
need there many other powerful features such as API Schema out of the 
box and better automation down that track.


It looks like the dream of a conduit between API services and 
consumers might have finally come true so we could move-on an worry 
about other things.


So has anyone already starting looking into it?

[1] 
https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql 


[2] http://graphql.org


Not to speak for him, but Sean Dague had a blog post about REST API 
microversions in OpenStack and there is a Q bit at the bottom about 
GraphQL replacing the need for microversions:


https://dague.net/2017/12/11/rest-api-microversions/

Since I don't expect Sean to magically appear to reply to this thread, 
I thought I'd pass this along.




Thanks Matt for the link.

During Denver's PTG we effectively discovered consumers tend to use 3rd 
party SDK and we also discovered that, ironically, nobody - besides Sean 
;) - has the bandwidth to work full time on SDK either. That was and 
still is the driver for more automation and therefore for having 
projects to produce an API Schema.


Once aspect is about GraphQL being a descriptive language. It allow to 
decouple entirely consumers from producers. So instead of SDK, consumers 
rely on GraphQL client library (which are standardized [1]). The focus 
becomes the data and not how to transfer the data.
Effectively, services make their data available through a Schema and 
clients request a tree of data against it. Sure, at the end of the day, 
it's still a HTTP conversation taking place and returning a JSON 
structure (when not up/down loading a file or so). The big difference 
(among other things) is one and only one transaction is used.


The second aspect is about automation which can take place because the 
Schema is provided up-front, it's the Graph part.


In the Q, Sean said SDK "build their object models", yes that's true 
with GraphQL we have "fat clients" but as we've also seen the SDK is 
replaced with a GraphQL client., cutting the "man in the middle" off!


As per the rest of the Answer, it seems to me there are other aspects to 
be looked at it from different angles.


Cheers

[1] http://graphql.org/code/



__
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] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

Yes, that’s was indeed the sens of my point.

Openstack have to provide both endpoints type for a while for backward
compatibility in order to smooth the transition.

For instance, that would be a good idea to contact postman devteam once
GraphQL will start to be integrated as it will allow a lot of ops to keep
their day to day tools by just having to convert their existing collections
of handful requests.

Or alternatively to provide a tool with similar features at least.
Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil  a écrit :

>
>
> On 30/04/18 20:16, Flint WALRUS wrote:
>
> I would very much second that question! Indeed it have been one of my own
> wondering since many times.
>
> Of course GraphQL is not intended to replace REST as is and have to live
> in parallel
>
>
> Effectively a standard initial architecture is to have GraphQL sitting
> aside (in parallel) and wrapping REST and along the way develop GrapgQL
> Schema.
>
> It's seems too early to tell but GraphQL being the next step in API
> evolution it might ultimately replace REST.
>
>
> but it would likely and highly accelerate all requests within heavily
> loaded environments
>
>
> +1
>
>
> .
>
> So +1 for this question.
> Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil  a
> écrit :
>
>> Hi,
>>
>> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
>> addresses REST limitations.
>> I wonder if any project has been thinking about using GraphQL. I haven't
>> find any mention or pointers about it.
>>
>> GraphQL takes a complete different approach compared to REST. So we can
>> finally forget about REST API Description languages
>> (OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
>> approach which doesn't describe how to use it).
>>
>> So, once passed the point where 'REST vs GraphQL' is like comparing SQL
>> and no-SQL DBMS and therefore have different applications, there are no
>> doubt the complexity of most OpenStack projects are good candidates for
>> GraphQL.
>>
>> Besides topics such as efficiency, decoupling, no version management
>> need there many other powerful features such as API Schema out of the
>> box and better automation down that track.
>>
>> It looks like the dream of a conduit between API services and consumers
>> might have finally come true so we could move-on an worry about other
>> things.
>>
>> So has anyone already starting looking into it?
>>
>> [1]
>>
>> https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
>> [2] http://graphql.org
>>
>>
>>
>> __
>> 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
>>
>
> --
> Gilles Dubreuil
> Senior Software Engineer - Red Hat - Openstack DFG Integration
> Email: gil...@redhat.com
> GitHub/IRC: gildub
> Mobile: +61 400 894 219
>
>
>
__
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] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

On 30/04/18 20:16, Flint WALRUS wrote:
I would very much second that question! Indeed it have been one of my 
own wondering since many times.


Of course GraphQL is not intended to replace REST as is and have to 
live in parallel 


Effectively a standard initial architecture is to have GraphQL sitting 
aside (in parallel) and wrapping REST and along the way develop GrapgQL 
Schema.


It's seems too early to tell but GraphQL being the next step in API 
evolution it might ultimately replace REST.


but it would likely and highly accelerate all requests within heavily 
loaded environments


+1


.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil > a écrit :


Hi,

Remember Boston's Summit presentation [1] about GraphQL [2] and
how it
addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I
haven't
find any mention or pointers about it.

GraphQL takes a complete different approach compared to REST. So
we can
finally forget about REST API Description languages
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
approach which doesn't describe how to use it).

So, once passed the point where 'REST vs GraphQL' is like
comparing SQL
and no-SQL DBMS and therefore have different applications, there
are no
doubt the complexity of most OpenStack projects are good
candidates for
GraphQL.

Besides topics such as efficiency, decoupling, no version management
need there many other powerful features such as API Schema out of the
box and better automation down that track.

It looks like the dream of a conduit between API services and
consumers
might have finally come true so we could move-on an worry about other
things.

So has anyone already starting looking into it?

[1]

https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
[2] http://graphql.org



__
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



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219

__
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] [api] REST limitations and GraghGL inception?

[Matt Riedemann]

On 4/29/2018 10:53 PM, Gilles Dubreuil wrote:
Remember Boston's Summit presentation [1] about GraphQL [2] and how it 
addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I haven't 
find any mention or pointers about it.


GraphQL takes a complete different approach compared to REST. So we can 
finally forget about REST API Description languages 
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia 
approach which doesn't describe how to use it).


So, once passed the point where 'REST vs GraphQL' is like comparing SQL 
and no-SQL DBMS and therefore have different applications, there are no 
doubt the complexity of most OpenStack projects are good candidates for 
GraphQL.


Besides topics such as efficiency, decoupling, no version management 
need there many other powerful features such as API Schema out of the 
box and better automation down that track.


It looks like the dream of a conduit between API services and consumers 
might have finally come true so we could move-on an worry about other 
things.


So has anyone already starting looking into it?

[1] 
https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql 


[2] http://graphql.org


Not to speak for him, but Sean Dague had a blog post about REST API 
microversions in OpenStack and there is a Q bit at the bottom about 
GraphQL replacing the need for microversions:


https://dague.net/2017/12/11/rest-api-microversions/

Since I don't expect Sean to magically appear to reply to this thread, I 
thought I'd pass this along.


--

Thanks,

Matt

__
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] [api] REST limitations and GraghGL inception?

[Flint WALRUS]

I would very much second that question! Indeed it have been one of my own
wondering since many times.

Of course GraphQL is not intended to replace REST as is and have to live in
parallel but it would likely and highly accelerate all requests within
heavily loaded environments.

So +1 for this question.
Le lun. 30 avr. 2018 à 05:53, Gilles Dubreuil  a
écrit :

> Hi,
>
> Remember Boston's Summit presentation [1] about GraphQL [2] and how it
> addresses REST limitations.
> I wonder if any project has been thinking about using GraphQL. I haven't
> find any mention or pointers about it.
>
> GraphQL takes a complete different approach compared to REST. So we can
> finally forget about REST API Description languages
> (OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia
> approach which doesn't describe how to use it).
>
> So, once passed the point where 'REST vs GraphQL' is like comparing SQL
> and no-SQL DBMS and therefore have different applications, there are no
> doubt the complexity of most OpenStack projects are good candidates for
> GraphQL.
>
> Besides topics such as efficiency, decoupling, no version management
> need there many other powerful features such as API Schema out of the
> box and better automation down that track.
>
> It looks like the dream of a conduit between API services and consumers
> might have finally come true so we could move-on an worry about other
> things.
>
> So has anyone already starting looking into it?
>
> [1]
>
> https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql
> [2] http://graphql.org
>
>
>
> __
> 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

[openstack-dev] [api] REST limitations and GraghGL inception?

[Gilles Dubreuil]

Hi,

Remember Boston's Summit presentation [1] about GraphQL [2] and how it 
addresses REST limitations.
I wonder if any project has been thinking about using GraphQL. I haven't 
find any mention or pointers about it.


GraphQL takes a complete different approach compared to REST. So we can 
finally forget about REST API Description languages 
(OpenAPI/Swagger/WSDL/WADL/JSON-API/ETC) and HATEOS (the hypermedia 
approach which doesn't describe how to use it).


So, once passed the point where 'REST vs GraphQL' is like comparing SQL 
and no-SQL DBMS and therefore have different applications, there are no 
doubt the complexity of most OpenStack projects are good candidates for 
GraphQL.


Besides topics such as efficiency, decoupling, no version management 
need there many other powerful features such as API Schema out of the 
box and better automation down that track.


It looks like the dream of a conduit between API services and consumers 
might have finally come true so we could move-on an worry about other 
things.


So has anyone already starting looking into it?

[1] 
https://www.openstack.org/videos/boston-2017/building-modern-apis-with-graphql

[2] http://graphql.org



__
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] [api] [lbaas] Neutron LBaaS V2 docs incompatibility

[Artem Goncharov]

Thanks a lot Michael.

On Fri, 27 Apr 2018, 19:57 Michael Johnson,  wrote:

> Hi Artem,
>
> You are correct that the API reference at
> https://developer.openstack.org/api-ref/network/v2/index.html#pools is
> incorrect. As you figured out, someone mistakenly merged the long
> dead/removed LBaaS v1 API specification into the LBaaS v2 API
> specification at that link.
>
> The current, and up to date load balancing API reference is at:
> https://developer.openstack.org/api-ref/load-balancer/v2/index.html
>
> This documents the Octavia API which is a superset of the the LBaaS v2
> API, so it should help you clarify any issues you run into.
>
> That said, due to the deprecation of neutron-lbaas and spin out from
> neutron we decided to explicitly not support neutron-lbaas in the
> OpenStack Client. neutron-lbaas is only supported using the neutron
> client.  You can continue to use the neutron client CLI with
> neutron-lbaas through the neutron-lbaas deprecation cycle.
>
> When you move to using Octavia you can switch to using the
> python-octaviaclient OSC plugin.
>
> Michael
>
> On Wed, Apr 25, 2018 at 5:51 AM, Artem Goncharov
>  wrote:
> > Hi all,
> >
> > after working with OpenStackSDK in my cloud I have found one difference
> in
> > the Neutron LBaaS (yes, I know it is deprecated, but it is still used).
> The
> > fix would be small and fast, unfortunately I have faced problems with the
> > API description:
> > - https://wiki.openstack.org/wiki/Neutron/LBaaS/API_2.0#Pools describes,
> > that the LB pool has healthmonitor_id attribute (what eventually also
> fits
> > reality of my cloud)
> > - https://developer.openstack.org/api-ref/network/v2/index.html#pools
> (which
> > is referred to from the previous link in the deprecation note) describes,
> > that the LB pool has healthmonitors (and healthmonitors_status) as list
> of
> > IDs. Basically in this regards it is same as
> > https://wiki.openstack.org/wiki/Neutron/LBaaS/API_1.0#Pool description
> > - unfortunately even
> >
> https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/lbaas-v2.inc
> > describes Pool.healthmonitors (however it also contains
> >
> https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/samples/lbaas/pools-list-response2.json
> > sample with the Pool.healthmonitor_id)
> > - OpenStackSDK contains network.pool.health_monitors (with underscore)
> >
> > I want to bring this all in an order and enable managing of the
> loadbalancer
> > through OSC for my OpenStack cloud, but I can't figure out what is the
> > correct behavior here.
> >
> > Can anybody, please, help in figuring out the truth here?
> >
> > Thanks,
> > Artem
> >
> >
> __
> > 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
>
__
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] [api] [lbaas] Neutron LBaaS V2 docs incompatibility

[Michael Johnson]

Hi Artem,

You are correct that the API reference at
https://developer.openstack.org/api-ref/network/v2/index.html#pools is
incorrect. As you figured out, someone mistakenly merged the long
dead/removed LBaaS v1 API specification into the LBaaS v2 API
specification at that link.

The current, and up to date load balancing API reference is at:
https://developer.openstack.org/api-ref/load-balancer/v2/index.html

This documents the Octavia API which is a superset of the the LBaaS v2
API, so it should help you clarify any issues you run into.

That said, due to the deprecation of neutron-lbaas and spin out from
neutron we decided to explicitly not support neutron-lbaas in the
OpenStack Client. neutron-lbaas is only supported using the neutron
client.  You can continue to use the neutron client CLI with
neutron-lbaas through the neutron-lbaas deprecation cycle.

When you move to using Octavia you can switch to using the
python-octaviaclient OSC plugin.

Michael

On Wed, Apr 25, 2018 at 5:51 AM, Artem Goncharov
 wrote:
> Hi all,
>
> after working with OpenStackSDK in my cloud I have found one difference in
> the Neutron LBaaS (yes, I know it is deprecated, but it is still used). The
> fix would be small and fast, unfortunately I have faced problems with the
> API description:
> - https://wiki.openstack.org/wiki/Neutron/LBaaS/API_2.0#Pools describes,
> that the LB pool has healthmonitor_id attribute (what eventually also fits
> reality of my cloud)
> - https://developer.openstack.org/api-ref/network/v2/index.html#pools (which
> is referred to from the previous link in the deprecation note) describes,
> that the LB pool has healthmonitors (and healthmonitors_status) as list of
> IDs. Basically in this regards it is same as
> https://wiki.openstack.org/wiki/Neutron/LBaaS/API_1.0#Pool description
> - unfortunately even
> https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/lbaas-v2.inc
> describes Pool.healthmonitors (however it also contains
> https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/samples/lbaas/pools-list-response2.json
> sample with the Pool.healthmonitor_id)
> - OpenStackSDK contains network.pool.health_monitors (with underscore)
>
> I want to bring this all in an order and enable managing of the loadbalancer
> through OSC for my OpenStack cloud, but I can't figure out what is the
> correct behavior here.
>
> Can anybody, please, help in figuring out the truth here?
>
> Thanks,
> Artem
>
> __
> 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

[openstack-dev] [api] [lbaas] Neutron LBaaS V2 docs incompatibility

[Artem Goncharov]

Hi all,

after working with OpenStackSDK in my cloud I have found one difference in
the Neutron LBaaS (yes, I know it is deprecated, but it is still used). The
fix would be small and fast, unfortunately I have faced problems with the
API description:
- https://wiki.openstack.org/wiki/Neutron/LBaaS/API_2.0#Pools describes,
that the LB pool has *healthmonitor_id* attribute (what eventually also
fits reality of my cloud)
- https://developer.openstack.org/api-ref/network/v2/index.html#pools
(which
is referred to from the previous link in the deprecation note) describes,
that the LB pool has *healthmonitors* (and *healthmonitors_status*) as list
of IDs. Basically in this regards it is same as
https://wiki.openstack.org/wiki/Neutron/LBaaS/API_1.0#Pool description
- unfortunately even
https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/lbaas-v2.inc
describes
*Pool.healthmonitors* (however it also contains
https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/samples/lbaas/pools-list-response2.json
sample
with the *Pool.healthmonitor_id*)
- OpenStackSDK contains *network.pool.health_monitors* (with underscore)

I want to bring this all in an order and enable managing of the
loadbalancer through OSC for my OpenStack cloud, but I can't figure out
what is the correct behavior here.

Can anybody, please, help in figuring out the truth here?

Thanks,
Artem
__
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] [api] Adding a SDK to developer.openstack.org pages

[Gilles Dubreuil]

On 06/04/18 22:37, Jeremy Stanley wrote:

On 2018-04-06 12:00:24 +1000 (+1000), Gilles Dubreuil wrote:

I'd like to update the developer.openstack.org to add details about a new
SDK.

What would be the corresponding repo? My searches landed me into
https://docs.openstack.org/doc-contrib-guide/ which is about updating the
docs.openstack.org but not developer.openstack.org. Is the developer section
inside the docs section?

Looks like we could do a better job of linking to the relevant git
repositories from some documents.

I think the file you're looking for is probably:

 https://git.openstack.org/cgit/openstack/api-site/tree/www/index.html

Happy hacking!


That's the one!

Thank you



__
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] [api] Adding a SDK to developer.openstack.org pages

[Jeremy Stanley]

On 2018-04-06 12:00:24 +1000 (+1000), Gilles Dubreuil wrote:
> I'd like to update the developer.openstack.org to add details about a new
> SDK.
> 
> What would be the corresponding repo? My searches landed me into
> https://docs.openstack.org/doc-contrib-guide/ which is about updating the
> docs.openstack.org but not developer.openstack.org. Is the developer section
> inside the docs section?

Looks like we could do a better job of linking to the relevant git
repositories from some documents.

I think the file you're looking for is probably:

https://git.openstack.org/cgit/openstack/api-site/tree/www/index.html

Happy hacking!
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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-dev] [api] Adding a SDK to developer.openstack.org pages

[Gilles Dubreuil]

Hi,

I'd like to update the developer.openstack.org to add details about a 
new SDK.


What would be the corresponding repo? My searches landed me into 
https://docs.openstack.org/doc-contrib-guide/ which is about updating 
the docs.openstack.org but not developer.openstack.org. Is the developer 
section inside the docs section?


Thanks,
Gilles


__
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] [api] [heat] microversion_parse.middleware.MicroversionMiddleware

[Chris Dent]

On Tue, 6 Mar 2018, Chris Dent wrote:


Last week at the PTG, during the API-SIG session, there was
discussion of extracting the microversion handling middleware that
is used in the placement service into the relatively small
microversion-parse library. This is so people who want to adopt
microversions (or change their implementation) can share some code.

This evening I've got a working version of that, and would like some
feedback (and a few other things as well).

The code is in a stack starting with https://review.openstack.org/#/c/495356/


This has merged and has been released as microversion-parse 0.2.1:

https://pypi.org/project/microversion_parse/


As a sort of proof, there's also a nova patchset which shows the
removed code. If you install the above stack into the checked out
nova patchset, it works as expected. That nova change is at
https://review.openstack.org/#/c/550265/


This has now been changed away from being a  DNM/WIP and depends on
a requirements change

https://review.openstack.org/#/c/555332/

These warts still remain


* It wants to use webob, because that's how it started out. This is
 pretty easy to fix with one challenge being managing error
 formatting.

* At the moment it is not yet set up to align with deployment
 strategies such as paste (it uses old school wsgi initialization
 and wrapping). Also pretty easy to fix.


but I wanted to get something out for people to experiment with. The
nova patchset is probably as a good a starting point for
understanding how to use it as anything.

Eventually it would probably make sense to create a little demo WSGI
app that uses it.


--
Chris Dent   ٩◔̯◔۶   https://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] [api] APAC-friendly API-SIG meeting times

[Gilles Dubreuil]

On 17/03/18 02:53, Ed Leafe wrote:

On Mar 15, 2018, at 10:31 PM, Gilles Dubreuil  wrote:

Any chance we can progress on this one?

I believe there are not enough participants to split the API SIG meeting in 2, 
and also more likely because of the same lack of people across the 2 it could 
make it pretty inefficient. Therefore I think changing the main meeting time to 
another might be better but I could be wrong.

Anyway in all cases I can't make progress with a meeting in the middle of the 
night for me so I would appreciate if we could re-activate this discussion.

What range of times would work for you?

-- Ed Leafe





I can do very early (like 6am), or alternatively late (10pm) if needed 
to avoid others to be in the red zone:

https://www.timeanddate.com/worldclock/meetingtime.html?day=31=3=2018=240=195=137=0

Of course assuming we're talking about spreading across the globe for a 
single meeting, otherwise that would be easier as I'm quite flex.




__
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] [api] APAC-friendly API-SIG meeting times

[Ed Leafe]

On Mar 15, 2018, at 10:31 PM, Gilles Dubreuil  wrote:
> 
> Any chance we can progress on this one?
> 
> I believe there are not enough participants to split the API SIG meeting in 
> 2, and also more likely because of the same lack of people across the 2 it 
> could make it pretty inefficient. Therefore I think changing the main meeting 
> time to another might be better but I could be wrong.
> 
> Anyway in all cases I can't make progress with a meeting in the middle of the 
> night for me so I would appreciate if we could re-activate this discussion.

What range of times would work for you? 

-- Ed Leafe






__
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] [api] APAC-friendly API-SIG meeting times

[Gilles Dubreuil]

Hi,

Any chance we can progress on this one?

I believe there are not enough participants to split the API SIG meeting 
in 2, and also more likely because of the same lack of people across the 
2 it could make it pretty inefficient. Therefore I think changing the 
main meeting time to another might be better but I could be wrong.


Anyway in all cases I can't make progress with a meeting in the middle 
of the night for me so I would appreciate if we could re-activate this 
discussion.


Thanks,
Gilles


On 13/12/17 02:22, Ed Leafe wrote:

Re-sending this in the hope of getting more responses. If you’re in the APAC 
region and interested in contributing to our discussions, please indicate your 
preferences on the link below.


That brought up another issue: the current meeting time for the API-SIG is 
1600UTC, which is not very convenient for APAC contributors. Gilles is in 
Australia, and so it was the middle of the night for him! As one of the goals 
for the API-SIG is to expand our audience and membership, edleafe committed to 
seeing if there is an available meeting slot at 2200UTC, which would be 
convenient for APAC, and still early enough for US people to attend. If an 
APAC-friendly meeting time would be good for you, please keep an eye out on the 
mailing list for an announcement if we are able to set that up, and then please 
attend and participate!

Looking at the current meeting schedule, there are openings at 2200UTC  on 
Tuesday, Wednesday, and Thursday mornings in APAC (Monday, Tuesday, and 
Wednesday afternoons in the US).

I’ve set up a doodle so that people can record their preferences:

https://doodle.com/poll/bec9gfff38zvh3ud

If you’re interested in attending API-SIG meetings, please fill out the form at 
that URL with your preferences. I’ll summarize the results at the next API-SIG 
meeting.


-- Ed Leafe






__
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


-- Ed Leafe






__
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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



__
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] [api-wg][api][neutron] How to handle invalid query parameters

[Ghanshyam Mann]

On Thu, Mar 8, 2018 at 6:12 AM, Chris Dent  wrote:
> On Wed, 7 Mar 2018, Hongbin Lu wrote:
>
>> As a brief recap, we were discussing how Neutron API server should behave
>> if invalid query parameters were inputted. Per my understanding, the general
>> consensus is to make Neutron API server behave consistently with other
>> OpenStack projects. The question for API-WG is if there is any guideline to
>> clarify how OpenStack projects should handle invalid query parameters. Query
>> parameters are various across different projects but it seems most projects
>> support these four categories of query parameters: sorting, pagination,
>> filtering, and fields selection. I saw API-WG provided a guideline to define
>> how to handle valid parameters of these categories [2], but it doesn’t seem
>> to define how to handle invalid parameters.
>>
>> I wonder if API-WG could clarify it. For example, if users provide an
>> invalid filter on listing the resources, should the API server ignore the
>> invalid filter and return a successful response? Or it should return an
>> error response? Below is a list of specific scenarios and examples to
>> consider:
>
>
> It's hard to find, but there's existing guidance that touches on
> this. From
> http://specs.openstack.org/openstack/api-wg/guidelines/http.html#failure-code-clarifications
> :
>
> [I]f the API supports query parameters and a request contains an
> unknown or unsupported parameter, the server should return a 400
> Bad Request response. Invalid values in the request URL should
> never be silently ignored, as the response may not match the
> client’s expectation. For example, consider the case where an
> API allows filtering on name by specifying ‘?name=foo’ in the
> query string, and in one such request there is a typo, such as
> ‘?nmae=foo’. If this error were silently ignored, the user would
> get back all resources instead of just the ones named ‘foo’,
> which would not be correct.  The error message that is returned
> should clearly indicate the problem so that the user could
> correct it and re-submit.
>
> This same logic can be applied to invalid fields used in parameters
> which can only accept a limited number of inputs (such as sort_key)
> so in the examples you give a 400 would be the way to ensure that
> the user agent is actually made aware that their request had issues.

+1. Nova also implemented query parameters validation using JSON
Schema [1] and 400 for few sorting param which were mainly joined
table and ignore others. We had to leave and ignore the unsupported
parameter as of now due to backward compatibility. But with newly
introduced API, we follow the above guidelines and 400 on any
additional or wrong parameter. Example [2].

>
> I hope this helps. Please let the api-sig know if you think we
> should adjust the guidelines to make this more explicit somehow.
>

..1 
https://github.com/openstack/nova/blob/c7b54a80ac25f6a01d0a150c546532f5ae2592ce/nova/api/openstack/compute/schemas/servers.py#L334
..2 
https://github.com/openstack/nova/blob/c7b54a80ac25f6a01d0a150c546532f5ae2592ce/nova/api/openstack/compute/schemas/migrations.py#L43

> --
> Chris Dent  (⊙＿⊙') https://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
>

__
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] [api-wg][api][neutron] How to handle invalid query parameters

[Hongbin Lu]

Hi all,

Please disregard the email below since I used the wrong template. Sorry about 
that. The email with the same content was re-sent in a new thread 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128022.html .

Best regards,
Hongbin

From: Hongbin Lu
Sent: March-07-18 4:02 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [api-wg][api][neutron] How to handle invalid query parameters

Hi all,

This is a follow-up for the discussion in Dublin PTG about how Neutron API 
server should handle invalid query parameter [1]. According to the feedback, I 
sent this ML to seek advice from API-WG in this regards.

As a brief recap, we were discussing how Neutron API server should behave if 
invalid query parameters were inputted. Per my understanding, the general 
consensus is to make Neutron API server behave consistently with other 
OpenStack projects. The question for API-WG is if there is any guideline to 
clarify how OpenStack projects should handle invalid query parameters. Query 
parameters are various across different projects but it seems most projects 
support these four categories of query parameters: sorting, pagination, 
filtering, and fields selection. I saw API-WG provided a guideline to define 
how to handle valid parameters of these categories [2], but it doesn’t seem to 
define how to handle invalid parameters.

I wonder if API-WG could clarify it. For example, if users provide an invalid 
filter on listing the resources, should the API server ignore the invalid 
filter and return a successful response? Or it should return an error response? 
Below is a list of specific scenarios and examples to consider:

1. Invalid sorting. For example:

  GET "/v2.0/networks?sort_dir=desc_key="
  GET "/v2.0/networks?sort_dir=_key=xxx"

2. Invalid pagination. For example:

  GET "/v2.0/networks?limit==xxx"
  GET "/v2.0/networks?limit=1="

3. Invalid filter. For example:

GET "/v2.0/networks?=xxx"
GET "/v2.0/networks?xxx="

4. Invalid field. For example:

  GET "/v2.0/networks?fields="

Best regards,
Hongbin

[1] https://bugs.launchpad.net/neutron/+bug/1749820
[2] 
https://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html



华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]


 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

__
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] [api-wg][api][neutron] How to handle invalid query parameters

[Chris Dent]

On Wed, 7 Mar 2018, Hongbin Lu wrote:


As a brief recap, we were discussing how Neutron API server should behave if 
invalid query parameters were inputted. Per my understanding, the general 
consensus is to make Neutron API server behave consistently with other 
OpenStack projects. The question for API-WG is if there is any guideline to 
clarify how OpenStack projects should handle invalid query parameters. Query 
parameters are various across different projects but it seems most projects 
support these four categories of query parameters: sorting, pagination, 
filtering, and fields selection. I saw API-WG provided a guideline to define 
how to handle valid parameters of these categories [2], but it doesn’t seem to 
define how to handle invalid parameters.

I wonder if API-WG could clarify it. For example, if users provide an invalid 
filter on listing the resources, should the API server ignore the invalid 
filter and return a successful response? Or it should return an error response? 
Below is a list of specific scenarios and examples to consider:


It's hard to find, but there's existing guidance that touches on
this. From
http://specs.openstack.org/openstack/api-wg/guidelines/http.html#failure-code-clarifications
 :

[I]f the API supports query parameters and a request contains an
unknown or unsupported parameter, the server should return a 400
Bad Request response. Invalid values in the request URL should
never be silently ignored, as the response may not match the
client’s expectation. For example, consider the case where an
API allows filtering on name by specifying ‘?name=foo’ in the
query string, and in one such request there is a typo, such as
‘?nmae=foo’. If this error were silently ignored, the user would
get back all resources instead of just the ones named ‘foo’,
which would not be correct.  The error message that is returned
should clearly indicate the problem so that the user could
correct it and re-submit.

This same logic can be applied to invalid fields used in parameters
which can only accept a limited number of inputs (such as sort_key)
so in the examples you give a 400 would be the way to ensure that
the user agent is actually made aware that their request had issues.

I hope this helps. Please let the api-sig know if you think we
should adjust the guidelines to make this more explicit somehow.

--
Chris Dent  (⊙＿⊙') https://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

[openstack-dev] [api-wg][api][neutron] How to handle invalid query parameters

[Hongbin Lu]

Hi all,

This is a follow-up for the discussion in Dublin PTG about how Neutron API 
server should handle invalid query parameter [1]. According to the feedback, I 
sent this ML to seek advice from API-WG in this regards.

As a brief recap, we were discussing how Neutron API server should behave if 
invalid query parameters were inputted. Per my understanding, the general 
consensus is to make Neutron API server behave consistently with other 
OpenStack projects. The question for API-WG is if there is any guideline to 
clarify how OpenStack projects should handle invalid query parameters. Query 
parameters are various across different projects but it seems most projects 
support these four categories of query parameters: sorting, pagination, 
filtering, and fields selection. I saw API-WG provided a guideline to define 
how to handle valid parameters of these categories [2], but it doesn't seem to 
define how to handle invalid parameters.

I wonder if API-WG could clarify it. For example, if users provide an invalid 
filter on listing the resources, should the API server ignore the invalid 
filter and return a successful response? Or it should return an error response? 
Below is a list of specific scenarios and examples to consider:

1. Invalid sorting. For example:

  GET "/v2.0/networks?sort_dir=desc_key="
  GET "/v2.0/networks?sort_dir=_key=xxx"

2. Invalid pagination. For example:

  GET "/v2.0/networks?limit==xxx"
  GET "/v2.0/networks?limit=1="

3. Invalid filter. For example:

GET "/v2.0/networks?=xxx"
GET "/v2.0/networks?xxx="

4. Invalid field. For example:

  GET "/v2.0/networks?fields="

Best regards,
Hongbin

[1] https://bugs.launchpad.net/neutron/+bug/1749820
[2] 
https://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html
__
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-dev] [api-wg][api][neutron] How to handle invalid query parameters

[Hongbin Lu]

Hi all,

This is a follow-up for the discussion in Dublin PTG about how Neutron API 
server should handle invalid query parameter [1]. According to the feedback, I 
sent this ML to seek advice from API-WG in this regards.

As a brief recap, we were discussing how Neutron API server should behave if 
invalid query parameters were inputted. Per my understanding, the general 
consensus is to make Neutron API server behave consistently with other 
OpenStack projects. The question for API-WG is if there is any guideline to 
clarify how OpenStack projects should handle invalid query parameters. Query 
parameters are various across different projects but it seems most projects 
support these four categories of query parameters: sorting, pagination, 
filtering, and fields selection. I saw API-WG provided a guideline to define 
how to handle valid parameters of these categories [2], but it doesn’t seem to 
define how to handle invalid parameters.

I wonder if API-WG could clarify it. For example, if users provide an invalid 
filter on listing the resources, should the API server ignore the invalid 
filter and return a successful response? Or it should return an error response? 
Below is a list of specific scenarios and examples to consider:

1. Invalid sorting. For example:

  GET "/v2.0/networks?sort_dir=desc_key="
  GET "/v2.0/networks?sort_dir=_key=xxx"

2. Invalid pagination. For example:

  GET "/v2.0/networks?limit==xxx"
  GET "/v2.0/networks?limit=1="

3. Invalid filter. For example:

GET "/v2.0/networks?=xxx"
GET "/v2.0/networks?xxx="

4. Invalid field. For example:

  GET "/v2.0/networks?fields="

Best regards,
Hongbin

[1] https://bugs.launchpad.net/neutron/+bug/1749820
[2] 
https://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html



华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]


 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

__
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-dev] [api] [heat] microversion_parse.middleware.MicroversionMiddleware

[Chris Dent]

Last week at the PTG, during the API-SIG session, there was
discussion of extracting the microversion handling middleware that
is used in the placement service into the relatively small
microversion-parse library. This is so people who want to adopt
microversions (or change their implementation) can share some code.

This evening I've got a working version of that, and would like some
feedback (and a few other things as well).

The code is in a stack starting with https://review.openstack.org/#/c/495356/

In total that stack of patches moves most of the microversion
handling code out of placement and adapts it (with some caveats) to
general use.

As a sort of proof, there's also a nova patchset which shows the
removed code. If you install the above stack into the checked out
nova patchset, it works as expected. That nova change is at
https://review.openstack.org/#/c/550265/

Right now the microversion-parse changes are pretty rough but I
don't want to go too far down the road of cleaning them up if the
approach is not going to work for people. Looking at the two
different patchsets will make some of the current limitations more
clear, but some that I'm aware of:

* It wants to use webob, because that's how it started out. This is
  pretty easy to fix with one challenge being managing error
  formatting.

* At the moment it is not yet set up to align with deployment
  strategies such as paste (it uses old school wsgi initialization
  and wrapping). Also pretty easy to fix.

There are some weird boundaries between version info used by the
application, and version info used by the middleware. In the case of
placement, there's some code left in placement for managing
different methods for different versions of requests to the same
URL. This kind of thing would be pretty nice to have in a library,
but the current implementation is very tied to the way placement
does dispatch. For services that already have their own routing
dispatch system, that's kind of a non-starter.

Anyway, if this is a topic of interest to you the code linked above
is available for review and experimentation. If it turns out to be
something people like I'll start the process of making a new release
and getting that release into global requirements.

The other things I'm thinking about are:

* microversion-parse needs more cores. Right now there are only
  three and two of those are unable to be super active in the
  community any more. If you are someone who has knowledge of
  microversions and WSGI middleware, look at the code, and let me
  know.

* If this code is going to be used outside of placement, it may make
  sense for it to go under the umbrella of oslo. I think we may have
  discussed that when the microversion-parse library was initially
  created and at the time I took a wait and see attitude. Is now the
  time? I don't know.

Thanks for your attention and feedback.

--
Chris Dent  (⊙＿⊙') https://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] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[Ed Leafe]

On Feb 2, 2018, at 2:11 AM, Duncan Thomas  wrote:
> 
> So I guess my question here is why is being RESTful good? Sure it's (very, 
> very loosely) a standard, but what are the actual advantages? Standards come 
> and go, what we want most of all is a good quality, easy to use API.

REST is HTTP. I don’t think that that is a “loose” standard by any measure.

> I'm not saying that going RESTful is wrong, but I don't see much discussion 
> about what the advantages are, only about how close we are to implementing it.

Here’s a quick summary of the advantages, courtesy of SO:

https://stackoverflow.com/questions/5320003/why-we-should-use-rest

REST is the standard for OpenStack APIs. Our job in the API-SIG is to help all 
projects develop their APIs to be as consistent as possible without using a 
top-down, heavy-handed approach. That’s why we included a suggestion for how to 
make your RPC-ish API consistent with other projects that also use an RPC-like 
approach to parts of their API.


-- Ed Leafe






__
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] [api] Openstack API and HTTP caching

[Chris Dent]

On Mon, 5 Feb 2018, Fred De Backer wrote:


Therefore it is my opinion that the Openstack API (Nova in this case, but
equally valid for all other APIs) should be responsible to include proper
HTTP headers in their responses to either disallow caching of the response
or at least limit it's validity.


Yeah, that is what should happen. We recently did it (disallow
caching) for placement
(http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/placement-cache-headers.html)
but it probably needs to be done just about everywhere else.

I'd suggest you create a bug (probably just a nova one for now, but
make it general enough that it is easy to add other projects) an
perhaps that will help get some traction.

--
Chris Dent  (⊙＿⊙') https://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

[openstack-dev] [api] Openstack API and HTTP caching

[Fred De Backer]

Hi there,

I recently hit an issue where I was using Terraform through an HTTP proxy
(enforced by my company IT) to provision some resources in an Openstack
cloud. Since creating the resources took some time, the initial response
from openstack was "still creating...". Further polling of the resource
status resulted in receiving *cached* copies of "still creating..." from
the proxy until time-out.

RFC7234 that describes HTTP caching states that in absence of all headers
describing the lifetime/validity of the response, heuristic algorithms may
be applied by caches to guesstimate an appropriate value for the validity
of the response... (Who knows what is implemented out there...) See: the
HTTP caching RFC section 4.2.2
.

The API responses describe the current state of an object which isn't
permanent, but has a limited validity. In fact very limited as the state of
an object might change any moment.

Therefore it is my opinion that the Openstack API (Nova in this case, but
equally valid for all other APIs) should be responsible to include proper
HTTP headers in their responses to either disallow caching of the response
or at least limit it's validity.

See the HTTP caching RFC section 5
 for headers that could be
used to accomplish that.
For sake of completeness; also see https://github.com/gophercloud
/gophercloud/issues/727 for my initial client-side fix and related
discussion with client-side project owners...

Regards,
Fred
__
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] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[Gilles Dubreuil]

As you said RESTful is not a standard but brings guidelines of good 
practices. Which in turn doesn't preclude adding ideas, as long as 
respecting RESTful approach. So we get from both sides.


Therefore a good schema structure adds to a de-facto standard, once the 
practice is commonly used.



On 02/02/18 19:11, Duncan Thomas wrote:
So I guess my question here is why is being RESTful good? Sure it's 
(very, very loosely) a standard, but what are the actual advantages? 
Standards come and go, what we want most of all is a good quality, 
easy to use API.


I'm not saying that going RESTful is wrong, but I don't see much 
discussion about what the advantages are, only about how close we are 
to implementing it.


On 1 Feb 2018 10:55 pm, "Ed Leafe" > wrote:


On Jan 18, 2018, at 4:07 AM, TommyLike Hu > wrote:

>    Recently We found an issue related to our OpenStack action
APIs. We usually expose our OpenStack APIs by registering them to
our API Gateway (for instance Kong [1]), but it becomes very
difficult when regarding to action APIs. We can not register and
control them seperately because them all share the same request
url which will be used as the identity in the gateway service, not
say rate limiting and other advanced gateway features, take a look
at the basic resources in OpenStack

We discussed your email at today’s API-SIG meeting [0]. This is an
area that is always contentious in the RESTful world. Actions,
tasks, and state changes are not actual resources, and in a pure
REST design they should never be part of the URL. Instead, you
should POST to the actual resource, with the desired action in the
body. So in your example:

> URL:/volumes/{volume_id}/action
> BODY:{'extend':{}}

the preferred way of achieving this is:

URL: POST /volumes/{volume_id}
BODY: {‘action’: ‘extend’, ‘params’: {}}

The handler for the POST action should inspect the body, and call
the appropriate method.

Having said that, we realize that a lot of OpenStack services have
adopted the more RPC-like approach that you’ve outlined. So while
we strongly recommend a standard RESTful approach, if you have
already released an RPC-like API, our advice is:

a) avoid having every possible verb in the URL. In other words,
don’t use:
  /volumes/{volume_id}/mount
  /volumes/{volume_id}/umount
  /volumes/{volume_id}/extend
This moves you further into RPC-land, and will make updating your
API to a more RESTful design more difficult.

b) choose a standard term for the item in the URL. In other words,
always use ‘action’ or ‘task’ or whatever else you have adopted.
Don’t mix terminology. Then pass the action to perform, along with
any parameters in the body. This will make it easier to transition
to a RESTful design by later updating the handlers to first
inspect the BODY instead of relying upon the URL to determine what
action to perform.

You might also want to contact the Kong developers to see if there
is a way to work with a RESTful API design.

-- Ed Leafe

[0]

http://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-02-01-16.02.log.html#l-28






__
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


__
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] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[Duncan Thomas]

So I guess my question here is why is being RESTful good? Sure it's (very,
very loosely) a standard, but what are the actual advantages? Standards
come and go, what we want most of all is a good quality, easy to use API.

I'm not saying that going RESTful is wrong, but I don't see much discussion
about what the advantages are, only about how close we are to implementing
it.

On 1 Feb 2018 10:55 pm, "Ed Leafe"  wrote:

> On Jan 18, 2018, at 4:07 AM, TommyLike Hu  wrote:
>
> >Recently We found an issue related to our OpenStack action APIs. We
> usually expose our OpenStack APIs by registering them to our API Gateway
> (for instance Kong [1]), but it becomes very difficult when regarding to
> action APIs. We can not register and control them seperately because them
> all share the same request url which will be used as the identity in the
> gateway service, not say rate limiting and other advanced gateway features,
> take a look at the basic resources in OpenStack
>
> We discussed your email at today’s API-SIG meeting [0]. This is an area
> that is always contentious in the RESTful world. Actions, tasks, and state
> changes are not actual resources, and in a pure REST design they should
> never be part of the URL. Instead, you should POST to the actual resource,
> with the desired action in the body. So in your example:
>
> > URL:/volumes/{volume_id}/action
> > BODY:{'extend':{}}
>
> the preferred way of achieving this is:
>
> URL: POST /volumes/{volume_id}
> BODY: {‘action’: ‘extend’, ‘params’: {}}
>
> The handler for the POST action should inspect the body, and call the
> appropriate method.
>
> Having said that, we realize that a lot of OpenStack services have adopted
> the more RPC-like approach that you’ve outlined. So while we strongly
> recommend a standard RESTful approach, if you have already released an
> RPC-like API, our advice is:
>
> a) avoid having every possible verb in the URL. In other words, don’t use:
>   /volumes/{volume_id}/mount
>   /volumes/{volume_id}/umount
>   /volumes/{volume_id}/extend
> This moves you further into RPC-land, and will make updating your API to a
> more RESTful design more difficult.
>
> b) choose a standard term for the item in the URL. In other words, always
> use ‘action’ or ‘task’ or whatever else you have adopted. Don’t mix
> terminology. Then pass the action to perform, along with any parameters in
> the body. This will make it easier to transition to a RESTful design by
> later updating the handlers to first inspect the BODY instead of relying
> upon the URL to determine what action to perform.
>
> You might also want to contact the Kong developers to see if there is a
> way to work with a RESTful API design.
>
> -- Ed Leafe
>
> [0] http://eavesdrop.openstack.org/meetings/api_sig/2018/api_
> sig.2018-02-01-16.02.log.html#l-28
>
>
>
>
> __
> 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] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[Ed Leafe]

On Jan 18, 2018, at 4:07 AM, TommyLike Hu  wrote:

>Recently We found an issue related to our OpenStack action APIs. We 
> usually expose our OpenStack APIs by registering them to our API Gateway (for 
> instance Kong [1]), but it becomes very difficult when regarding to action 
> APIs. We can not register and control them seperately because them all share 
> the same request url which will be used as the identity in the gateway 
> service, not say rate limiting and other advanced gateway features, take a 
> look at the basic resources in OpenStack

We discussed your email at today’s API-SIG meeting [0]. This is an area that is 
always contentious in the RESTful world. Actions, tasks, and state changes are 
not actual resources, and in a pure REST design they should never be part of 
the URL. Instead, you should POST to the actual resource, with the desired 
action in the body. So in your example:

> URL:/volumes/{volume_id}/action
> BODY:{'extend':{}}

the preferred way of achieving this is:

URL: POST /volumes/{volume_id}
BODY: {‘action’: ‘extend’, ‘params’: {}}

The handler for the POST action should inspect the body, and call the 
appropriate method.

Having said that, we realize that a lot of OpenStack services have adopted the 
more RPC-like approach that you’ve outlined. So while we strongly recommend a 
standard RESTful approach, if you have already released an RPC-like API, our 
advice is:

a) avoid having every possible verb in the URL. In other words, don’t use:
  /volumes/{volume_id}/mount
  /volumes/{volume_id}/umount
  /volumes/{volume_id}/extend
This moves you further into RPC-land, and will make updating your API to a more 
RESTful design more difficult.

b) choose a standard term for the item in the URL. In other words, always use 
‘action’ or ‘task’ or whatever else you have adopted. Don’t mix terminology. 
Then pass the action to perform, along with any parameters in the body. This 
will make it easier to transition to a RESTful design by later updating the 
handlers to first inspect the BODY instead of relying upon the URL to determine 
what action to perform.

You might also want to contact the Kong developers to see if there is a way to 
work with a RESTful API design.

-- Ed Leafe

[0] 
http://eavesdrop.openstack.org/meetings/api_sig/2018/api_sig.2018-02-01-16.02.log.html#l-28




__
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-dev] [api] Idea for a simple way to expose compute driver capabilities in the REST API

[Matt Riedemann]

We've talked about a type of capabilities API within nova and across 
OpenStack for at least a couple of years (earliest formal session I 
remember is a session in BCN).


At the PTG in Denver, I think there was general sentiment that rather 
than never do anything because we can't come up with the perfect design 
that would satisfy all requirements in all projects, we should just do 
our own things in the projects, at least as a start, and as long as 
things are well-documented, that's good enough rather than do nothing.


Well I'm not sure why but I was thinking about this problem today and 
came up with something simple here:


https://review.openstack.org/#/c/538498/

This builds on the change to pass ironic node traits through the 
nova-compute resource tracker and push those into placement on the 
compute node resource provider resource. These traits can then be tied 
to required traits in a flavor and used for scheduling.


The patch takes the existing ComputeDriver.capabilities dict that is on 
all compute drivers, and for the supported capabilities, exposes those 
as a CUSTOM_COMPUTE_ trait on the compute node resource 
provider. So for example, a compute node backed by a libvirt driver with 
qemu<2.10 would have a CUSTOM_COMPUTE_SUPPORTS_MULTIATTACH trait.


We could then add something to the request spec when booting a server 
from a mutltiattach volume to say this request requires a compute node 
that has that trait. That's one of the gaps we have with multiattach 
support today, which is there is no connection between the request for a 
multiattach-volume-backed server and the compute host the scheduler 
picks to build that server, which could lead to server create failures 
(which aren't rescheduled by the way).


Anyway, it's just an idea and I wanted to see what others thought about 
this. Doing it would bake a certain behavior into how things are tied to 
the placement REST API, and I'm not sure if that's a good thing or not. 
It also opens up the question of whether or not these become standard 
traits in the os-traits library.


Alternatively I've always thought we could do something simple like add 
a "GET /os-hypervisors/{hypervisor_id}/capabilities" API which either 
makes an RPC call to the compute to get the driver capabilities, or we 
could store the driver capabilities in the compute_nodes table and the 
API could pull them from there. Then we could build on that same type of 
idea by doing something like "GET /servers/{server_id}/capabilities" 
which would take into account the capabilities based on the compute host 
that the instance is running on, it's flavor, etc. That's all a bigger 
change though, but it's more direct than just passing things through to 
placement. I fear it's also something that might never happen because 
it'll get bogged down in a design committee.


--

Thanks,

Matt

__
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] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[TommyLike Hu]

Thanks Hongbin, These links are useful for me!

Hongbin Lu <hongbin...@huawei.com>于2018年1月20日周六 上午3:20写道：

> I remembered there are several discussions about action APIs in the past.
> This is one discussion I can find:
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109136.html
> . An obvious alternative is to expose each action with an independent API
> endpoint. For example:
>
>
>
> * POST /servers//start:Start a server
>
> * POST /servers//stop:Stop a server
>
> * POST /servers//reboot:Reboot a server
>
> * POST /servers//pause:Pause a server
>
>
>
> Several people pointed out the pros and cons of either approach and other
> alternatives [1] [2] [3]. Eventually, we (OpenStack Zun team) have adopted
> the alternative approach [4] above and it works very well from my
> perspective. However, I understand that there is no consensus on this
> approach within the OpenStack community.
>
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109178.html
>
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109208.html
>
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109248.html
>
> [4]
> https://developer.openstack.org/api-ref/application-container/#manage-containers
>
>
>
> Best regards,
>
> Hongbin
>
>
>
> *From:* TommyLike Hu [mailto:tommylik...@gmail.com]
> *Sent:* January-18-18 5:07 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify
> action name in request url
>
>
>
> Hey all,
>
>Recently We found an issue related to our OpenStack action APIs. We
> usually expose our OpenStack APIs by registering them to our API Gateway
> (for instance Kong [1]), but it becomes very difficult when regarding to
> action APIs. We can not register and control them seperately because them
> all share the same request url which will be used as the identity in the
> gateway service, not say rate limiting and other advanced gateway features,
> take a look at the basic resources in OpenStack
>
>
>
>1. *Server*: "/servers/{server_id}/action"  35+ APIs are include.
>
>2. *Volume*: "/volumes/{volume_id}/action"  14 APIs are include.
>
>3. Other resource
>
>
>
> We have tried to register different interfaces with same upstream url,
> such as:
>
>
>
>   * api gateway*: /version/resource_one/action/action1 =>* upstream*:
> /version/resource_one/action
>
> *   api gateway*: /version/resource_one/action/action2 =>* upstream*:
> /version/resource_one/action
>
>
>
> But it's not secure enough cause we can pass action2 in the request body
> while invoking /action/action1, also, try to read the full body for route
> is not supported by most of the api gateways(maybe plugins) and will have a
> performance impact when proxy. So my question is do we have any solution or
> suggestion for this case? Could we support specify action name both in
> request body and url such as:
>
>
>
> *URL:/volumes/{volume_id}/action*
>
> *BODY:*{'extend':{}}
>
>
>
> and:
>
>
>
> *URL:/volumes/{volume_id}/action/extend*
>
> *BODY:* {'extend':{}}
>
>
>
> Thanks
>
> Tommy
>
>
>
> [1]: https://github.com/Kong/kong
> __
> 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] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[Hongbin Lu]

I remembered there are several discussions about action APIs in the past. This 
is one discussion I can find: 
http://lists.openstack.org/pipermail/openstack-dev/2016-December/109136.html . 
An obvious alternative is to expose each action with an independent API 
endpoint. For example:

* POST /servers//start:Start a server
* POST /servers//stop:Stop a server
* POST /servers//reboot:Reboot a server
* POST /servers//pause:Pause a server

Several people pointed out the pros and cons of either approach and other 
alternatives [1] [2] [3]. Eventually, we (OpenStack Zun team) have adopted the 
alternative approach [4] above and it works very well from my perspective. 
However, I understand that there is no consensus on this approach within the 
OpenStack community.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109178.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109208.html
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-December/109248.html
[4] 
https://developer.openstack.org/api-ref/application-container/#manage-containers

Best regards,
Hongbin

From: TommyLike Hu [mailto:tommylik...@gmail.com]
Sent: January-18-18 5:07 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action 
name in request url

Hey all,
   Recently We found an issue related to our OpenStack action APIs. We usually 
expose our OpenStack APIs by registering them to our API Gateway (for instance 
Kong [1]), but it becomes very difficult when regarding to action APIs. We can 
not register and control them seperately because them all share the same 
request url which will be used as the identity in the gateway service, not say 
rate limiting and other advanced gateway features, take a look at the basic 
resources in OpenStack

   1. Server: "/servers/{server_id}/action"  35+ APIs are include.
   2. Volume: "/volumes/{volume_id}/action"  14 APIs are include.
   3. Other resource

We have tried to register different interfaces with same upstream url, such as:

   api gateway: /version/resource_one/action/action1 => upstream: 
/version/resource_one/action
   api gateway: /version/resource_one/action/action2 => upstream: 
/version/resource_one/action

But it's not secure enough cause we can pass action2 in the request body while 
invoking /action/action1, also, try to read the full body for route is not 
supported by most of the api gateways(maybe plugins) and will have a 
performance impact when proxy. So my question is do we have any solution or 
suggestion for this case? Could we support specify action name both in request 
body and url such as:

URL:/volumes/{volume_id}/action
BODY:{'extend':{}}

and:

URL:/volumes/{volume_id}/action/extend
BODY: {'extend':{}}

Thanks
Tommy

[1]: https://github.com/Kong/kong
__
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-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[TommyLike Hu]

Hey all,
   Recently We found an issue related to our OpenStack action APIs. We
usually expose our OpenStack APIs by registering them to our API Gateway
(for instance Kong [1]), but it becomes very difficult when regarding to
action APIs. We can not register and control them seperately because them
all share the same request url which will be used as the identity in the
gateway service, not say rate limiting and other advanced gateway features,
take a look at the basic resources in OpenStack

   1. *Server*: "/servers/{server_id}/action"  35+ APIs are include.
   2. *Volume*: "/volumes/{volume_id}/action"  14 APIs are include.
   3. Other resource

We have tried to register different interfaces with same upstream url, such
as:

  * api gateway*: /version/resource_one/action/action1 =>* upstream*:
/version/resource_one/action
*   api gateway*: /version/resource_one/action/action2 =>* upstream*:
/version/resource_one/action

But it's not secure enough cause we can pass action2 in the request body
while invoking /action/action1, also, try to read the full body for route
is not supported by most of the api gateways(maybe plugins) and will have a
performance impact when proxy. So my question is do we have any solution or
suggestion for this case? Could we support specify action name both in
request body and url such as:

*URL:*/volumes/{volume_id}/action
*BODY:*{'extend':{}}

and:

*URL:*/volumes/{volume_id}/action/extend
*BODY:* {'extend':{}}

Thanks
Tommy

[1]: https://github.com/Kong/kong
__
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] [api] APIs schema consumption discussion

[Graham Hayes]

On 22/11/17 20:04, Graham Hayes wrote:



> When I was talking to Gil about it, I suggested writing a new sphinx /
> docutils formatter. I am not sure how feasible it would be, but it could
> be possible (as sphinx has the whole page tree in memory when writing it
> out, we may be able to output it in some sort of structured format.
> 
> I would be hesitant to change how we write docs - this change took long
> enough to get in place, and the ability to add / remove bits to suit
> different projects is a good thing. Pages like [1] would be hard to do
> in a standard machine readable format, and I think they definitely make
> the docs better.
> 
> - Graham
> 
> 1 - https://developer.openstack.org/api-ref/compute/#servers-servers
> 
> 

Ok, I have done a quick (read: very rough and hacky) prototype of the
formatter here [1]

It uses the sphinx formatter plugin system, and reads from what we
already have in the api-ref/* folder.

It outputs [2] yaml that describes each endpoint, and the fields in the
request / response.

If there is interest, I can clean up the patch, and look at supporting
microversions.

1 - https://review.openstack.org/#/c/528801/
2 - http://paste.openstack.org/show/629241/

- Graham

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



signature.asc
Description: OpenPGP digital signature
__
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] [api] APAC-friendly API-SIG meeting times

[Ghanshyam Mann]

Thanks edleafe,

I am interested to attend but it is little early for me(i am in
JST(UTC +9)), any chance we can make it to 23:00 UTC or 0:00 UTC ?


-gmann


On Wed, Dec 13, 2017 at 12:22 AM, Ed Leafe  wrote:
> Re-sending this in the hope of getting more responses. If you’re in the APAC 
> region and interested in contributing to our discussions, please indicate 
> your preferences on the link below.
>
>>> That brought up another issue: the current meeting time for the API-SIG is 
>>> 1600UTC, which is not very convenient for APAC contributors. Gilles is in 
>>> Australia, and so it was the middle of the night for him! As one of the 
>>> goals for the API-SIG is to expand our audience and membership, edleafe 
>>> committed to seeing if there is an available meeting slot at 2200UTC, which 
>>> would be convenient for APAC, and still early enough for US people to 
>>> attend. If an APAC-friendly meeting time would be good for you, please keep 
>>> an eye out on the mailing list for an announcement if we are able to set 
>>> that up, and then please attend and participate!
>>
>> Looking at the current meeting schedule, there are openings at 2200UTC  on 
>> Tuesday, Wednesday, and Thursday mornings in APAC (Monday, Tuesday, and 
>> Wednesday afternoons in the US).
>>
>> I’ve set up a doodle so that people can record their preferences:
>>
>> https://doodle.com/poll/bec9gfff38zvh3ud
>>
>> If you’re interested in attending API-SIG meetings, please fill out the form 
>> at that URL with your preferences. I’ll summarize the results at the next 
>> API-SIG meeting.
>>
>>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>>
>> __
>> 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
>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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] [api] APAC-friendly API-SIG meeting times

[Gilles Dubreuil]

Obviously, I'm interested and I voted.

Thanks,
Gilles


On 13/12/17 02:22, Ed Leafe wrote:

Re-sending this in the hope of getting more responses. If you’re in the APAC 
region and interested in contributing to our discussions, please indicate your 
preferences on the link below.


That brought up another issue: the current meeting time for the API-SIG is 
1600UTC, which is not very convenient for APAC contributors. Gilles is in 
Australia, and so it was the middle of the night for him! As one of the goals 
for the API-SIG is to expand our audience and membership, edleafe committed to 
seeing if there is an available meeting slot at 2200UTC, which would be 
convenient for APAC, and still early enough for US people to attend. If an 
APAC-friendly meeting time would be good for you, please keep an eye out on the 
mailing list for an announcement if we are able to set that up, and then please 
attend and participate!

Looking at the current meeting schedule, there are openings at 2200UTC  on 
Tuesday, Wednesday, and Thursday mornings in APAC (Monday, Tuesday, and 
Wednesday afternoons in the US).

I’ve set up a doodle so that people can record their preferences:

https://doodle.com/poll/bec9gfff38zvh3ud

If you’re interested in attending API-SIG meetings, please fill out the form at 
that URL with your preferences. I’ll summarize the results at the next API-SIG 
meeting.


-- Ed Leafe






__
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


-- Ed Leafe






__
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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



__
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] [api] APAC-friendly API-SIG meeting times

[Ed Leafe]

Re-sending this in the hope of getting more responses. If you’re in the APAC 
region and interested in contributing to our discussions, please indicate your 
preferences on the link below.

>> That brought up another issue: the current meeting time for the API-SIG is 
>> 1600UTC, which is not very convenient for APAC contributors. Gilles is in 
>> Australia, and so it was the middle of the night for him! As one of the 
>> goals for the API-SIG is to expand our audience and membership, edleafe 
>> committed to seeing if there is an available meeting slot at 2200UTC, which 
>> would be convenient for APAC, and still early enough for US people to 
>> attend. If an APAC-friendly meeting time would be good for you, please keep 
>> an eye out on the mailing list for an announcement if we are able to set 
>> that up, and then please attend and participate!
> 
> Looking at the current meeting schedule, there are openings at 2200UTC  on 
> Tuesday, Wednesday, and Thursday mornings in APAC (Monday, Tuesday, and 
> Wednesday afternoons in the US). 
> 
> I’ve set up a doodle so that people can record their preferences:
> 
> https://doodle.com/poll/bec9gfff38zvh3ud
> 
> If you’re interested in attending API-SIG meetings, please fill out the form 
> at that URL with your preferences. I’ll summarize the results at the next 
> API-SIG meeting.
> 
> 
> -- Ed Leafe
> 
> 
> 
> 
> 
> 
> __
> 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


-- Ed Leafe






__
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-dev] [api] APAC-friendly API-SIG meeting times

[Ed Leafe]

On Dec 7, 2017, at 11:22 AM, Ed Leafe  wrote:

> That brought up another issue: the current meeting time for the API-SIG is 
> 1600UTC, which is not very convenient for APAC contributors. Gilles is in 
> Australia, and so it was the middle of the night for him! As one of the goals 
> for the API-SIG is to expand our audience and membership, edleafe committed 
> to seeing if there is an available meeting slot at 2200UTC, which would be 
> convenient for APAC, and still early enough for US people to attend. If an 
> APAC-friendly meeting time would be good for you, please keep an eye out on 
> the mailing list for an announcement if we are able to set that up, and then 
> please attend and participate!

Looking at the current meeting schedule, there are openings at 2200UTC  on 
Tuesday, Wednesday, and Thursday mornings in APAC (Monday, Tuesday, and 
Wednesday afternoons in the US). 

I’ve set up a doodle so that people can record their preferences:

https://doodle.com/poll/bec9gfff38zvh3ud

If you’re interested in attending API-SIG meetings, please fill out the form at 
that URL with your preferences. I’ll summarize the results at the next API-SIG 
meeting.


-- Ed Leafe






__
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] [api] api-sig weekly meeting time change request

[Gilles Dubreuil]

On 05/12/17 01:55, michael mccune wrote:

On 12/03/2017 10:26 PM, Gilles Dubreuil wrote:

Hi,

Could we please change the API SIG weekly meeting time from 16pm UTC 
to 19pm UTC  [1]?

To give a chance for those down under to attend?


hey Gilles,

we have proposed adding another meeting time to make things easier for 
folks in the APAC regions. sadly, every time we have brought this up 
the response has been lackluster from people in that region.


i think the group is willing to discuss having a meeting time to 
enable APAC but it would be helpful to have a good indication of who 
the meeting would serve as pushing the time back by 3 hours will 
negatively impact the EMEA folks. i had sent this survey[1] to the 
mailing list but didn't get much response.




Two meetings makes sense to avoid stretching the first one out of normal 
hours (not even talking about business hours).
Although I'm not sure how active is the APAC region on either producer 
or consumer sides. Well there is me at least, +1 for the survey.



Thanks,
Gilles


peace o/

[1]: https://goo.gl/forms/0mVV4TGT7bZGAK323



Cheers,
Gilles

[1] 
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20171204=195=137=240 








__
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] [api] api-sig weekly meeting time change request

[michael mccune]

On 12/03/2017 10:26 PM, Gilles Dubreuil wrote:

Hi,

Could we please change the API SIG weekly meeting time from 16pm UTC to 
19pm UTC  [1]?

To give a chance for those down under to attend?


hey Gilles,

we have proposed adding another meeting time to make things easier for 
folks in the APAC regions. sadly, every time we have brought this up the 
response has been lackluster from people in that region.


i think the group is willing to discuss having a meeting time to enable 
APAC but it would be helpful to have a good indication of who the 
meeting would serve as pushing the time back by 3 hours will negatively 
impact the EMEA folks. i had sent this survey[1] to the mailing list but 
didn't get much response.


peace o/

[1]: https://goo.gl/forms/0mVV4TGT7bZGAK323



Cheers,
Gilles

[1] 
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20171204=195=137=240 






__
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] [api] api-sig weekly meeting time change request

[Gilles Dubreuil]

Never mind, I just the schedule document [1].

I'll push a request there.

[1] http://eavesdrop.openstack.org/#API_Working_Group


On 04/12/17 14:26, Gilles Dubreuil wrote:

Hi,

Could we please change the API SIG weekly meeting time from 16pm UTC 
to 19pm UTC  [1]?

To give a chance for those down under to attend?

Cheers,
Gilles

[1] 
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20171204=195=137=240




--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



__
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-dev] [api] api-sig weekly meeting time change request

[Gilles Dubreuil]

Hi,

Could we please change the API SIG weekly meeting time from 16pm UTC to 
19pm UTC  [1]?

To give a chance for those down under to attend?

Cheers,
Gilles

[1] 
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20171204=195=137=240



__
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] [api] APIs schema consumption discussion

[Gilles Dubreuil]

On 23/11/17 07:04, Graham Hayes wrote:


On 16/11/17 01:56, Gilles Dubreuil wrote:

On 15/11/17 03:07, Doug Hellmann wrote:

Excerpts from Gilles Dubreuil's message of 2017-11-14 10:15:02 +1100:

Hi,

Follow-up conversation from our last "API SIG feedback and discussion
session" at Sydney Summit [1], about APIs schema consumption.

Let's summarize the current situation.

Each OpenStack project has an "API-source" folder containing RST files
describing its API structure ([2] for example). Those files are in turn
consumed by the Sphinx library to generate each project's API reference
manual which are then available in the API guide documentation [3]. Such
effort has made the APIs harmoniously consistent across all OpenStack
projects and has also created a "de-facto" API schema.

While the RST files are used by the documentation, they are not readily
consumable by SDKs. Of course the APIs schema can be extracted by web
crawling the Reference guides, which in turn can be used by any
language. Such approach works [4] and help the Misty project [5] (Ruby
SDK) started with more languages to exploit the same approach.

Therefore to allow better automation, the next step would be to have the
APIs schema stored directly into each project's repo so the SDKs could
consume them straight from the source. This is why we've started
discussing how to have the schema either extracted from the RST files or
alternatively having the API described directly into its own file. The
latter would provide a different work flow: "Yaml -> RST -> Reference
doco" instead of "RST -> Reference doco -> Yaml".

So the question at this stage is: "Which of the work flow to choose
from?".

To clarify the needs, it's important to note that we found out that none
of the SDKs project, besides OSC (OpenStack Client, thanks to Dean),
have full time working teams to maintain each SDK, which besides the
natural structural complexity inherent to the cloud context, makes the
task of keeping a SDK up to date very difficult. Especially as projects
moves forward. Automatically managing Openstack APIs is inevitable for
consumers. Another example/feedback was provided by the presenters of
"AT’s Strategy for Implementing a Next Generation OpenStack Cloud"
session during Sydney Keynotes, as they don't handle the Openstack API
manually!

APIs consumers and providers, any thoughts?

[1]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session

[2] https://github.com/openstack/nova/tree/master/api-guide/source
[3] https://developer.openstack.org/api-guide/quick-start/index.html
[4] https://github.com/flystack/openstack-APIs
[5] https://github.com/flystack/misty

Regards,
Gilles

Please do not build something that looks like SOAP based on parsing RST
files. Surely we can at least work directly from JSONSchema inputs?

I'm glad you said that :).
Working directly from YAML or JSON files (format to be discussed) to
maintain the schema seems (to me too) the natural approach.

Meaning every project to change current practice: maintain the schema
files instead of maintaining RST files.
I suppose there has been suggestion to do it the other way (parse the
RST files) because of the latter impact on the current practice, but it
shouldn't be a blocker.

Gil


When I was talking to Gil about it, I suggested writing a new sphinx /
docutils formatter. I am not sure how feasible it would be, but it could
be possible (as sphinx has the whole page tree in memory when writing it
out, we may be able to output it in some sort of structured format.


That makes sense if the tree is already loaded, could you please provide 
a pointer?




I would be hesitant to change how we write docs - this change took long
enough to get in place, and the ability to add / remove bits to suit
different projects is a good thing. Pages like [1] would be hard to do
in a standard machine readable format, and I think they definitely make
the docs better.


First off, let me insist: "The reference guides are absolutely great". I 
guess that's the ransom of the success! :)
So, from outside (as a blackbox) the doc generation process, it made 
sense to have a work flow going from a structured tree to the docs, 
meanwhile if the same information can be obtained from the existing that 
sounds good.




- Graham

1 - https://developer.openstack.org/api-ref/compute/#servers-servers



__
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


--
Gil

__
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] [api] APIs schema consumption discussion

[Graham Hayes]

On 16/11/17 01:56, Gilles Dubreuil wrote:
> 
> On 15/11/17 03:07, Doug Hellmann wrote:
>> Excerpts from Gilles Dubreuil's message of 2017-11-14 10:15:02 +1100:
>>> Hi,
>>>
>>> Follow-up conversation from our last "API SIG feedback and discussion
>>> session" at Sydney Summit [1], about APIs schema consumption.
>>>
>>> Let's summarize the current situation.
>>>
>>> Each OpenStack project has an "API-source" folder containing RST files
>>> describing its API structure ([2] for example). Those files are in turn
>>> consumed by the Sphinx library to generate each project's API reference
>>> manual which are then available in the API guide documentation [3]. Such
>>> effort has made the APIs harmoniously consistent across all OpenStack
>>> projects and has also created a "de-facto" API schema.
>>>
>>> While the RST files are used by the documentation, they are not readily
>>> consumable by SDKs. Of course the APIs schema can be extracted by web
>>> crawling the Reference guides, which in turn can be used by any
>>> language. Such approach works [4] and help the Misty project [5] (Ruby
>>> SDK) started with more languages to exploit the same approach.
>>>
>>> Therefore to allow better automation, the next step would be to have the
>>> APIs schema stored directly into each project's repo so the SDKs could
>>> consume them straight from the source. This is why we've started
>>> discussing how to have the schema either extracted from the RST files or
>>> alternatively having the API described directly into its own file. The
>>> latter would provide a different work flow: "Yaml -> RST -> Reference
>>> doco" instead of "RST -> Reference doco -> Yaml".
>>>
>>> So the question at this stage is: "Which of the work flow to choose
>>> from?".
>>>
>>> To clarify the needs, it's important to note that we found out that none
>>> of the SDKs project, besides OSC (OpenStack Client, thanks to Dean),
>>> have full time working teams to maintain each SDK, which besides the
>>> natural structural complexity inherent to the cloud context, makes the
>>> task of keeping a SDK up to date very difficult. Especially as projects
>>> moves forward. Automatically managing Openstack APIs is inevitable for
>>> consumers. Another example/feedback was provided by the presenters of
>>> "AT’s Strategy for Implementing a Next Generation OpenStack Cloud"
>>> session during Sydney Keynotes, as they don't handle the Openstack API
>>> manually!
>>>
>>> APIs consumers and providers, any thoughts?
>>>
>>> [1]
>>> https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session
>>>
>>> [2] https://github.com/openstack/nova/tree/master/api-guide/source
>>> [3] https://developer.openstack.org/api-guide/quick-start/index.html
>>> [4] https://github.com/flystack/openstack-APIs
>>> [5] https://github.com/flystack/misty
>>>
>>> Regards,
>>> Gilles
>> Please do not build something that looks like SOAP based on parsing RST
>> files. Surely we can at least work directly from JSONSchema inputs?
> 
> I'm glad you said that :).
> Working directly from YAML or JSON files (format to be discussed) to
> maintain the schema seems (to me too) the natural approach.
> 
> Meaning every project to change current practice: maintain the schema
> files instead of maintaining RST files.
> I suppose there has been suggestion to do it the other way (parse the
> RST files) because of the latter impact on the current practice, but it
> shouldn't be a blocker.
> 
> Gil
> 

When I was talking to Gil about it, I suggested writing a new sphinx /
docutils formatter. I am not sure how feasible it would be, but it could
be possible (as sphinx has the whole page tree in memory when writing it
out, we may be able to output it in some sort of structured format.

I would be hesitant to change how we write docs - this change took long
enough to get in place, and the ability to add / remove bits to suit
different projects is a good thing. Pages like [1] would be hard to do
in a standard machine readable format, and I think they definitely make
the docs better.

- Graham

1 - https://developer.openstack.org/api-ref/compute/#servers-servers



signature.asc
Description: OpenPGP digital signature
__
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] [api] APIs schema consumption discussion

[Gilles Dubreuil]

On 15/11/17 03:07, Doug Hellmann wrote:

Excerpts from Gilles Dubreuil's message of 2017-11-14 10:15:02 +1100:

Hi,

Follow-up conversation from our last "API SIG feedback and discussion
session" at Sydney Summit [1], about APIs schema consumption.

Let's summarize the current situation.

Each OpenStack project has an "API-source" folder containing RST files
describing its API structure ([2] for example). Those files are in turn
consumed by the Sphinx library to generate each project's API reference
manual which are then available in the API guide documentation [3]. Such
effort has made the APIs harmoniously consistent across all OpenStack
projects and has also created a "de-facto" API schema.

While the RST files are used by the documentation, they are not readily
consumable by SDKs. Of course the APIs schema can be extracted by web
crawling the Reference guides, which in turn can be used by any
language. Such approach works [4] and help the Misty project [5] (Ruby
SDK) started with more languages to exploit the same approach.

Therefore to allow better automation, the next step would be to have the
APIs schema stored directly into each project's repo so the SDKs could
consume them straight from the source. This is why we've started
discussing how to have the schema either extracted from the RST files or
alternatively having the API described directly into its own file. The
latter would provide a different work flow: "Yaml -> RST -> Reference
doco" instead of "RST -> Reference doco -> Yaml".

So the question at this stage is: "Which of the work flow to choose from?".

To clarify the needs, it's important to note that we found out that none
of the SDKs project, besides OSC (OpenStack Client, thanks to Dean),
have full time working teams to maintain each SDK, which besides the
natural structural complexity inherent to the cloud context, makes the
task of keeping a SDK up to date very difficult. Especially as projects
moves forward. Automatically managing Openstack APIs is inevitable for
consumers. Another example/feedback was provided by the presenters of
"AT’s Strategy for Implementing a Next Generation OpenStack Cloud"
session during Sydney Keynotes, as they don't handle the Openstack API
manually!

APIs consumers and providers, any thoughts?

[1]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session
[2] https://github.com/openstack/nova/tree/master/api-guide/source
[3] https://developer.openstack.org/api-guide/quick-start/index.html
[4] https://github.com/flystack/openstack-APIs
[5] https://github.com/flystack/misty

Regards,
Gilles

Please do not build something that looks like SOAP based on parsing RST
files. Surely we can at least work directly from JSONSchema inputs?


I'm glad you said that :).
Working directly from YAML or JSON files (format to be discussed) to 
maintain the schema seems (to me too) the natural approach.


Meaning every project to change current practice: maintain the schema 
files instead of maintaining RST files.
I suppose there has been suggestion to do it the other way (parse the 
RST files) because of the latter impact on the current practice, but it 
shouldn't be a blocker.


Gil



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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



__
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] [api] APIs schema consumption discussion

[Doug Hellmann]

Excerpts from Gilles Dubreuil's message of 2017-11-14 10:15:02 +1100:
> Hi,
> 
> Follow-up conversation from our last "API SIG feedback and discussion 
> session" at Sydney Summit [1], about APIs schema consumption.
> 
> Let's summarize the current situation.
> 
> Each OpenStack project has an "API-source" folder containing RST files 
> describing its API structure ([2] for example). Those files are in turn 
> consumed by the Sphinx library to generate each project's API reference 
> manual which are then available in the API guide documentation [3]. Such 
> effort has made the APIs harmoniously consistent across all OpenStack 
> projects and has also created a "de-facto" API schema.
> 
> While the RST files are used by the documentation, they are not readily 
> consumable by SDKs. Of course the APIs schema can be extracted by web 
> crawling the Reference guides, which in turn can be used by any 
> language. Such approach works [4] and help the Misty project [5] (Ruby 
> SDK) started with more languages to exploit the same approach.
> 
> Therefore to allow better automation, the next step would be to have the 
> APIs schema stored directly into each project's repo so the SDKs could 
> consume them straight from the source. This is why we've started 
> discussing how to have the schema either extracted from the RST files or 
> alternatively having the API described directly into its own file. The 
> latter would provide a different work flow: "Yaml -> RST -> Reference 
> doco" instead of "RST -> Reference doco -> Yaml".
> 
> So the question at this stage is: "Which of the work flow to choose from?".
> 
> To clarify the needs, it's important to note that we found out that none 
> of the SDKs project, besides OSC (OpenStack Client, thanks to Dean), 
> have full time working teams to maintain each SDK, which besides the 
> natural structural complexity inherent to the cloud context, makes the 
> task of keeping a SDK up to date very difficult. Especially as projects 
> moves forward. Automatically managing Openstack APIs is inevitable for 
> consumers. Another example/feedback was provided by the presenters of 
> "AT’s Strategy for Implementing a Next Generation OpenStack Cloud" 
> session during Sydney Keynotes, as they don't handle the Openstack API 
> manually!
> 
> APIs consumers and providers, any thoughts?
> 
> [1] 
> https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session
> [2] https://github.com/openstack/nova/tree/master/api-guide/source
> [3] https://developer.openstack.org/api-guide/quick-start/index.html
> [4] https://github.com/flystack/openstack-APIs
> [5] https://github.com/flystack/misty
> 
> Regards,
> Gilles

Please do not build something that looks like SOAP based on parsing RST
files. Surely we can at least work directly from JSONSchema inputs?

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

[openstack-dev] [api] APIs schema consumption discussion

[Gilles Dubreuil]

Hi,

Follow-up conversation from our last "API SIG feedback and discussion 
session" at Sydney Summit [1], about APIs schema consumption.


Let's summarize the current situation.

Each OpenStack project has an "API-source" folder containing RST files 
describing its API structure ([2] for example). Those files are in turn 
consumed by the Sphinx library to generate each project's API reference 
manual which are then available in the API guide documentation [3]. Such 
effort has made the APIs harmoniously consistent across all OpenStack 
projects and has also created a "de-facto" API schema.


While the RST files are used by the documentation, they are not readily 
consumable by SDKs. Of course the APIs schema can be extracted by web 
crawling the Reference guides, which in turn can be used by any 
language. Such approach works [4] and help the Misty project [5] (Ruby 
SDK) started with more languages to exploit the same approach.


Therefore to allow better automation, the next step would be to have the 
APIs schema stored directly into each project's repo so the SDKs could 
consume them straight from the source. This is why we've started 
discussing how to have the schema either extracted from the RST files or 
alternatively having the API described directly into its own file. The 
latter would provide a different work flow: "Yaml -> RST -> Reference 
doco" instead of "RST -> Reference doco -> Yaml".


So the question at this stage is: "Which of the work flow to choose from?".

To clarify the needs, it's important to note that we found out that none 
of the SDKs project, besides OSC (OpenStack Client, thanks to Dean), 
have full time working teams to maintain each SDK, which besides the 
natural structural complexity inherent to the cloud context, makes the 
task of keeping a SDK up to date very difficult. Especially as projects 
moves forward. Automatically managing Openstack APIs is inevitable for 
consumers. Another example/feedback was provided by the presenters of 
"AT’s Strategy for Implementing a Next Generation OpenStack Cloud" 
session during Sydney Keynotes, as they don't handle the Openstack API 
manually!


APIs consumers and providers, any thoughts?

[1] 
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20442/api-sig-feedback-and-discussion-session

[2] https://github.com/openstack/nova/tree/master/api-guide/source
[3] https://developer.openstack.org/api-guide/quick-start/index.html
[4] https://github.com/flystack/openstack-APIs
[5] https://github.com/flystack/misty

Regards,
Gilles

__
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] [api][nova] Why we return a redirect (302) when request to 'GET /v2.1'?

[Alex Xu]

2017-11-02 20:42 GMT+08:00 Sean Dague :

> On 11/01/2017 11:04 PM, Alex X wrote:
>
>> There is bug complain about the redirect which returned by the 'GET
>> /v2.1' https://launchpad.net/bugs/1728732
>>
>> 'GET /v2.1' will return a redirect to the 'GET /v2.1/'. The response of
>> 'GET /v2.1/' is the API version info. This seems nova API behaviour for a
>> long time.
>>
>> In the keystone catalog, the endpoint should be the version API I think.
>> For nova, it is 'GET /v2.1' which return a redirect instead of version info.
>>
>> Is there anybody knowing that why we return a redirect?
>>
>
> I thought it was an artifact of the way that paste builds pipelines, and
> the way our resources need urls. I was trying to see if we generate it on
> our side, but I'm not seeing it, so I suspect this is just a consequence of
> the resource mapper and paste.


It is generated it on our side
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/routes.py#L410



>
>
> -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
>
__
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] [api][nova] Why we return a redirect (302) when request to 'GET /v2.1'?

[Sean Dague]

On 11/01/2017 11:04 PM, Alex X wrote:
There is bug complain about the redirect which returned by the 'GET 
/v2.1' https://launchpad.net/bugs/1728732


'GET /v2.1' will return a redirect to the 'GET /v2.1/'. The response of 
'GET /v2.1/' is the API version info. This seems nova API behaviour for 
a long time.


In the keystone catalog, the endpoint should be the version API I think. 
For nova, it is 'GET /v2.1' which return a redirect instead of version info.


Is there anybody knowing that why we return a redirect?


I thought it was an artifact of the way that paste builds pipelines, and 
the way our resources need urls. I was trying to see if we generate it 
on our side, but I'm not seeing it, so I suspect this is just a 
consequence of the resource mapper and paste.


-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

[openstack-dev] [api][nova] Why we return a redirect (302) when request to 'GET /v2.1'?

[Alex Xu]

There is bug complain about the redirect which returned by the 'GET /v2.1'
https://launchpad.net/bugs/1728732

'GET /v2.1' will return a redirect to the 'GET /v2.1/'. The response of
'GET /v2.1/' is the API version info. This seems nova API behaviour for a
long time.

In the keystone catalog, the endpoint should be the version API I think.
For nova, it is 'GET /v2.1' which return a redirect instead of version info.

Is there anybody knowing that why we return a redirect?

Thanks
Alex
__
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] [api-wg][glance] call for comments on Glance spec for Queens

[Adam Heczko]

Thank you Brian!
+1 for solving this, I left my comments in review.


On Fri, Sep 29, 2017 at 12:00 PM, Luke Hinds  wrote:

>
>
> On Fri, Sep 29, 2017 at 3:08 AM, Brian Rosmaita <
> rosmaita.foss...@gmail.com> wrote:
>
>> Hello API WG,
>>
>> I've got a patch up for a proposal to fix OSSN-0075 by introducing a
>> new policy.  There are concerns that this will introduce an
>> interoperability problem in that an API call that works in one
>> OpenStack cloud may not work in other OpenStack clouds.  As author of
>> the spec, I think this is an OK trade-off to fix the security issue,
>> but not all members of the Glance community agree, so we're trying to
>> get some wider perspective.  We'd appreciate it if some API-WG members
>> could take a look and leave a comment:
>>
>> https://review.openstack.org/#/c/468179/
>>
>> If you could respond by Tuesday 3 October, that would give us time to
>> get this worked out before the spec freeze (6 October).
>>
>> thanks,
>> brian
>>
>>
> +1 for efforts to take this forward and find a resolution, from a security
> standpoint it would be good to see this solved.
>
> Luke
>
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> 
>>
>
> __
> 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
>
>


-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
__
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] [api-wg][glance] call for comments on Glance spec for Queens

[Luke Hinds]

On Fri, Sep 29, 2017 at 3:08 AM, Brian Rosmaita 
wrote:

> Hello API WG,
>
> I've got a patch up for a proposal to fix OSSN-0075 by introducing a
> new policy.  There are concerns that this will introduce an
> interoperability problem in that an API call that works in one
> OpenStack cloud may not work in other OpenStack clouds.  As author of
> the spec, I think this is an OK trade-off to fix the security issue,
> but not all members of the Glance community agree, so we're trying to
> get some wider perspective.  We'd appreciate it if some API-WG members
> could take a look and leave a comment:
>
> https://review.openstack.org/#/c/468179/
>
> If you could respond by Tuesday 3 October, that would give us time to
> get this worked out before the spec freeze (6 October).
>
> thanks,
> brian
>
>
+1 for efforts to take this forward and find a resolution, from a security
standpoint it would be good to see this solved.

Luke

__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
> 
>
__
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