[Feature Request] Change API Endpoint Generation

[palexster]

Polycube Extension Proposals

Abstract

Current approach to API generation and management is complex. In particular, it is complex to:

• Have discoverable APIs (i.e. HATEOS)
• Introduce endpoints to scrape metrics (e.g. /metrics) by querying existing cubes on specific methods (e.g. metrics scraping)

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:

1. Generate a API tree, with nodes defined with the following information:
   • Node Name
   • Node Type
   • Pointers to implemented methods
   • Metadata
     This API Tree should be kept update upon update-removal of existing services
     This will enable the following features:

• Instrumentation-Metrics Exposition
• Hateoas API Support

Second step:

2. Split the discovery of APIs and their binding. This will have the following benefit:

• Simplify the API Server code
• Decouple the logic of endpoint binding from the YANG parser

[DavideAG]

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.
The routes used for endpoints are dynamic.

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.
I report for example the part of code that is used to generate endpoints for a "Container" and the part associated with a "RestLeaf".
The information that will then be used to invoke the specific methods of each module is then currently extracted from the yang parsing. Decoupling the current operation of yang parsing and subsequent generation of endpoints would involve storing the parameters to be used for the invocation of the functions.
With the implementation of the tree it would then be necessary to retrace the whole tree and generate the endpoints according to the node type.

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.
The modification of the separation of the yang parsing operations and consequent binding therefore involves an important change in the current operation of the polycubed web server.

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.
Considering that such operations would not affect the export of the metrics we need anyway.

So we ask for your judgment in this matter @sebymiano @michelsciortino @mauriciovasquezbernal.

Thank you in advance!

[frisso]

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.

[DavideAG]

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.
I can partecipate both days