Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>