-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Change API Endpoint Generation #276
Comments
With @pinoOgni we studied the current operation of the yang parser and the generation of endpoints. Currently the yang of each service is processed iteratively and each of its modules is, according to its type, treated differently. (as we can see from this switch case). The endpoints are then generated at the declaration of a Resources::Endpoint::ParentResource. We have seen that the information to be used to generate endpoints are various and differ for the type of yang module we want to parsing. The generation of a tree about APIs is still an operation that would allow the support of Hateoas and to export the metrics that @pinoOgni needs. With @pinoOgni we wondered if it was really necessary to separate these two operations or just generate an API tree that would be sufficient to support Hateoas and export the required metrics. So we wondered if it was necessary to proceed with the decoupling of the yang parsing and subsequent binding of the endpoints or if these operations could be done as they are currently done. So we ask for your judgment in this matter @sebymiano @michelsciortino @mauriciovasquezbernal. Thank you in advance! |
My point is that we can definitely go for the generation of the API, which looks fair enough for the time being. However, to understand the implications of the process, I would suggest to schedule a confcall among the invoved people. I can suggest either Tue or Wed, after 4.00pm. |
Fine. |
Polycube Extension Proposals
Abstract
Current approach to API generation and management is complex. In particular, it is complex to:
The objective of this PEP is to make API generation mechanism, flexible enough to support those scenarios.
Current Solution
The Polycube Daemon does not keep track of information about cubes endpoints and cubes methods references. This prevents the possibility to use the these informations in future operations.
Limitations
The Polycube Daemon does not keep track of information about cubes and endpoints. This prevents the possibility to use the discovered endpoints in future operations.
Proposal
First step:
This API Tree should be kept update upon update-removal of existing services
This will enable the following features:
Second step:
The text was updated successfully, but these errors were encountered: