Create OpenAPI spec for CloudLaunch #109
Labels
Comments
|
I'm currently working on this. |
|
TODO:
|
|
@machristie this is so cool! Can you please document what you are doing. We might want to do the same for whole Galaxy and you experience can be priceless! |
4 tasks
|
Moved from: #95
Additional references: |
|
@bgruening will do! @nuwang thanks for these resources! Looks like I don't need to create a Swagger renderer after all. |
machristie
added a commit
to machristie/cloudlaunch
that referenced
this issue
Nov 2, 2017
Using the simple openapi clientFollowing the OpenAPI/Swagger instructions on this page. Also Django REST Framework docs Create a new virtualenv for the clientGetting an application listIssues:
|
|
@machristie This is looking great! Did you have to annotate things manually using CoreAPI, or did it pick up most of the required data from DRF automatically? Also, is there any advantage in using django-rest-swagger or does that generate the Swagger web UI only? |
|
@nuwang As a first step I didn't do any manual annotating or anything, just to see what is available out of the box. This is all automatically generated at this time. You can see in this commit that there's almost nothing to it. However, as I mentioned above, this is probably not sufficient. django-rest-swagger generates the Swagger web UI but also the schema document. So that seems like a good advantage to using it, otherwise we'd need to implement it. |
|
Ok, that's good to hear. basic auth was explicitly disabled, as I recall it was either because it was not particularly secure when not using https, or because it kept popping up the dialogue or maybe both. However, it looks like token auth should work? |
|
There is a bug preventing the setting of the Authorization header in coreapi-cli. To workaround this I downgraded Here are the steps to authenticate with the command line client:
Note: the Also: with auth configured I'm now seeing |
|
There's a typo in the coreapi docs: there is no |
machristie
added a commit
to machristie/cloudlaunch
that referenced
this issue
Nov 7, 2017
|
As I discussed with Nuwan today, it would be nice if the schema was aware of the hierarchy of REST URLs, like these Core API examples. For example, you could get a deployment and that becomes your context and from there you can get a list of tasks, etc. for that deployment. As you can see above, the generated schema is flat. django-rest-swagger generates the openapi/swagger schema based the coreapi autogenerated schema provided by django-rest-framework. One option might be to manually specify a coreapi schema that utilizes nested documents. However, even if we did that I'm not sure how that would be rendered by swagger since swagger seems unable to model hierarchies of URLs. We also probably don't want the overhead of manually specifying schemas in the first place. I'm going to investigate code generation and see what generated client code looks like and then decide whether it makes sense to customize the schema. |
Generating code with AutoRestBasically following these instructions. This fails because I need a more recent version of node. I downloaded 8.9.1 LTS release from https://nodejs.org/en/. Now I can install autorest Save the schema document to a file: Try to generate Python code This appears to fail because the Now I can generate Python code The generated code looks pretty weird. Maybe the schema needs some work or maybe options need to be passed to AutoRest. There are two immediate problems I see:
def list(
self, custom_headers=None, raw=False, **operation_config):
"""List authentication endpoints.
List authentication endpoints.
:param dict custom_headers: headers that will be added to the request
:param bool raw: returns the direct response alongside the
deserialized response
:param operation_config: :ref:`Operation configuration
overrides<msrest:optionsforoperations>`.
:return: None or
:class:`ClientRawResponse<msrest.pipeline.ClientRawResponse>` if
raw=true
:rtype: None or
:class:`ClientRawResponse<msrest.pipeline.ClientRawResponse>`
:raises:
:class:`HttpOperationError<msrest.exceptions.HttpOperationError>`
"""
# Construct URL
url = '/api/v1/auth/'
... def list1(
self, custom_headers=None, raw=False, **operation_config):
"""Calls Django logout method and delete the Token object.
Calls Django logout method and delete the Token object
assigned to the current User object.
Accepts/Returns nothing.
:param dict custom_headers: headers that will be added to the request
:param bool raw: returns the direct response alongside the
deserialized response
:param operation_config: :ref:`Operation configuration
overrides<msrest:optionsforoperations>`.
:return: None or
:class:`ClientRawResponse<msrest.pipeline.ClientRawResponse>` if
raw=true
:rtype: None or
:class:`ClientRawResponse<msrest.pipeline.ClientRawResponse>`
:raises:
:class:`HttpOperationError<msrest.exceptions.HttpOperationError>`
"""
# Construct URL
url = '/api/v1/auth/logout/'
...
|
Trying out drf_openapiInstalled drf_openapi and following the drf_openapi quickstart guide.
'DEFAULT_VERSIONING_CLASS': 'rest_framework.versioning.URLPathVersioning',and changed API prefix to have a named capturing group named API_PREFIX = r'api/(?P<version>v1)/'
To fix I had to install from source.
Once I had it setup, here's what it looks like when interacted with via coreapi client So this schema is even flatter than the one produced by django-rest-swagger, although in practice it doesn't make much difference. Here I get a list of applications: Other observations:
|
machristie
added a commit
to machristie/cloudlaunch
that referenced
this issue
Nov 20, 2017
Ran into a bug in 1.0.0 drf_openapi and had to install from source. This also required upgrading Django to 3.7.3 (different schema module layout). Also drf_openapi requires URLPathVersioning which I enabled.
Trying out AutoRest against drf_openapi schema outputThis produces similarly bad results, although it seems to fail halfway through. It doesn't generate any operations code, only models. Somewhere along the way it seems like the names of the models are getting lost or maybe they need to be specified somehow. I'm trying to figure out if that is possible. |
|
Summarizing discussion with Nuwan and Enis:
|
|
I've been able to integrate the coreapi schema and then write a simple Python script to use the coreapi client and list a user's AWS credentials: from coreapi import Client
from coreapi import transports
auth_token = '...'
transports = [
transports.HTTPTransport(credentials={'localhost': 'Token {}'.format(auth_token)})
]
client = Client(transports=transports)
document = client.get('http://localhost:8000/api/v1/schema/')
aws_credentials_list = client.action(document, ['auth', 'user', 'credentials', 'aws', 'list'])
print(aws_credentials_list)With this as a staring point it should make developing a command line client much simpler. Still to do are to see how to handle specifying a launch config file and how that works. One additional note: I found a good working version for coreapi is 2.2.3. Later ones run into two bugs: |
machristie
added a commit
to machristie/cloudlaunch
that referenced
this issue
Dec 1, 2017
|
@afgane This issue can be closed now. There some follow on work still on-going:
|
|
Thanks for seeing this through, and the summary of the follow-up tasks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
CloudLaunch exposes a REST API for manipulating IaaS infrastructure and CloudLaunch-specific appliance management functionality that would be great to have language-specific bindings for. OpenAPI spec, probably using swagger.io tools, seems like the best way to go about generating the bindings.
The text was updated successfully, but these errors were encountered: