Inject reference to swagger/Open API for service binding

[brendandobbs]

Description

This relates to YSF-2848 - Modify the swagger file when uploading it to Minio (PR : https://github.com/kyma-project/kyma/pull/36).

We have a swagger API doc stored in Minio with the host/basePath modified so that we can access the gateway directly when using a Swagger client.

What's missing to complete this is an easier way to reference the swagger doc in minio. For now I am looking in minio and searching for the service class content with the API documentation.

To easily allow us to use a client generator we could inject another environment variable (e.g. API_DOC_URL) that points to the file in minio.

[derberg]

Please take a look on my proposal for changes in documentation arch: https://github.com/kyma-project/community/pull/107/files

in simple words docs would have CRD and its controller would update the CR status with references to exact minio locations: https://github.com/kyma-project/community/pull/107/files#diff-02ae6e3a1cb8a1a3d841966a92e70fd6R85

please take a look and share feedback

[brendandobbs]

Thanks @derberg , the proposed changes look good from my point of view. It doesn't completely cover my request above. Currently when creating a ServiceBindingUsage for a Service Class (with spec document stored), we only get one environment variable for the Service Instance (GATEWAY_URL). Some changes would also be required to inject a new evironment variable with the location of the spec document (swagger, EDMX)?

[derberg]

@brendandobbs Interesting requirement, could you share some details why you want to do it? why you need a spec url in a secret?

[brendandobbs]

@derberg, we are using a swagger client which generates a client API at runtime but we need the URL of the swagger docs to initialize the client. Here is some sample code. Easiest to show with an example:

`const swaggerClient = await Swagger({url: process.env.API_DOC_URL});

// get order from Commerce var order = await swaggerClient.apis.Orders.getOrderUsingGET({code: event.data.orderCode, baseSiteId:'electronics'});`

We would also need the URL to the documentation (EDMX file) if we are consuming an OData service with an OData client.

[derberg]

@brendandobbs this is temporary right? I guess we do not want to long term do it this way, I mean generate/initialise the client on lambda runtime is kind of resource consuming and speed affecting process. Isn't it better to do it only once? for example the proposal I showed, the DocsTopic controller could do that once, during swagger (and other specs) processing and then expose all the links on CR status level? so client is then generated once and then reused.

The EDMX files should be treated similar, as short term solution and long term as well. So at the end the secret would contain specsURLs object for now with swagger, asyncapi and odata specs url.

[stale[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[derberg]

@brendandobbs this ticket was marked as stale. Could you confirm if it is really invalid and we can close it? if not, please answer the question ;)

[stale[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed due to the lack of recent activity.

[joek]

@derberg I think having the links as a env variable is anyway a good thing, as people might not like our clients or would like to use it in a microservice with strange programming language.

I agree we have to have follow up tasks on this to make it easier to use. Here are multiple solutions available which are probably different for each programming language. Still we need this information as part of an env variable ;-)

[stale[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[derberg]

@PK85 I think you can take it over for implementation, app registration uses already headless cms so links to specs are now easily accessible and can be added to the secret during service binding creation

[stale[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed due to the lack of recent activity.

[stale[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed due to the lack of recent activity.