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

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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[openstack-dev] [api] microversion-parse core updates

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]

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

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

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

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

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

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

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

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

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

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.

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

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

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

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,

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

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

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

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

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

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

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

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

Re: [openstack-dev] [api] [cinder] backup restore in api v2

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?

Re: [openstack-dev] [api] [cinder] backup restore in api v2

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

Re: [openstack-dev] [api] [cinder] backup restore in api v2

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 >

[openstack-dev] [api] [cinder] backup restore in api v2

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

[openstack-dev] [api] notes from api-sig forum meeting on graphql experiment

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

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

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

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

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

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

> >> Thanks, >> Kevin >> >> From: Jay Pipes [jaypi...@gmail.com <mailto:jaypi...@gmail.com>] >> Sent: Thursday, May 03, 2018 10:50 AM >> To:

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

follow declarative approach. >> > >> > That said a mutation following control plane API action semantic could >> > be very similar: >> > >> > mutation rebootServer { >> > Server(id: ) { >> > reboot: { >> >

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

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

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

quot; being an alias to name the request. > > > > > >> Even without using GraphQL, Making the api more declarative anyway, > >> has advantages. > > > > +1 > > > >> Thanks, > >> Kevin > >> ___

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

ay 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 pr

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

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

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

+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

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

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 Ma

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

Re: [openstack-dev] [api] Adding a SDK to developer.openstack.org pages

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/

Re: [openstack-dev] [api] Adding a SDK to developer.openstack.org pages

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 >

[openstack-dev] [api] Adding a SDK to developer.openstack.org pages

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

Re: [openstack-dev] [api] [heat] microversion_parse.middleware.MicroversionMiddleware

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

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

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

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

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

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

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

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

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

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

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

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

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

[openstack-dev] [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

[openstack-dev] [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

[openstack-dev] [api] [heat] microversion_parse.middleware.MicroversionMiddleware

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)

Re: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

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

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

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

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

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

Re: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

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.

Re: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

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

Re: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

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

[openstack-dev] [api] Idea for a simple way to expose compute driver capabilities in the REST API

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

Re: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

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

Re: [openstack-dev] [api-wg] [api] [cinder] [nova] Support specify action name in request url

[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 r

[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

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

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

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

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

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

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

Re: [openstack-dev] [api] APAC-friendly API-SIG meeting times

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

[openstack-dev] [api] APAC-friendly API-SIG meeting times

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

Re: [openstack-dev] [api] api-sig weekly meeting time change request

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

Re: [openstack-dev] [api] api-sig weekly meeting time change request

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

Re: [openstack-dev] [api] api-sig weekly meeting time change request

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

[openstack-dev] [api] api-sig weekly meeting time change request

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [openstack-dev] [api-wg][glance] call for comments on Glance spec for Queens

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

Re: [openstack-dev] [api-wg][glance] call for comments on Glance spec for Queens

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

  1   2   3   4   5   6   7   8   9   >