Closed itaru2622 closed 1 year ago
@fno2010 clould you review this PR, please.
Patch coverage: 100.00
% and project coverage change: +0.02
:tada:
Comparison is base (
b7e8a8b
) 79.67% compared to head (37049f0
) 79.69%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
It is a good idea to leverage OpenAPI. But I don't see the openapi.yaml
file in this commit.
I feel the openapi.yaml
should be a part of configuration file (etc/alto.conf
or a YANG data instance later), or generated by the configuration.
@fno2010 thank you for reviewing and response.
I want to confirm what you meant.
I think, there is some ways to generate and provide openapi.yaml
for generation timing a. command execution in terminal and store it as static file. b. when it gets access to some REST endpoint
for providing
I took choices as {B,2} in this PR at current. in this choice, there is no gap between running source codes and openapi.yaml.
Do you mean you want to choose A as generation and configure providing way (1or 2) by configiration? note that this choice causes a gap between source codes and openapi.yaml when developer missed executing A after modification.
moreover, I am wondering if A can provide correct openapi definition for running environment because REST paths can be changed by configuration (alto.conf) at starting time.
I can add a parameter in alto.conf to controlling turn on/off {B,2} feature.
@itaru2622 Many thanks for your clarification. I misunderstood this PR. I thought it was trying to use OpenAPI to generate northbound code. But clearly, I'm wrong. It provides OpenAPI spec based on the running northbound so that other tools (e.g., OAM) can read it. Then it makes sense to me.
Fix #45
OpenAPI specification is generated from code and can be got by curl -X GET http://alto-frontend:8000/openapi.yaml This feature is powered by https://www.django-rest-framework.org/api-guide/schemas/#generating-an-openapi-schema