The suggested resolution is to define an include file with the syntaxVersion element. The syntaxVersion element contains the component name and version number; the including interface definition file corresponds to the conf_mode script. Hence, this defines a mapping

https://github.com/vyos/vyatta-cfg-system/pull/144

There are two issues in this task (1) reordering of interfaces (2) redundant hw-id entries due to vyatta_net_name not parsing quoted values. A quick fix for (2) will be a PR for vyatta-cfg-system; the general issues the bug raises, regarding quoted values in configtree, will be addressed in the subtasks.

This is resolved by T3412.

Draft PR linked below; it is a draft pending the addition of a supporting package (vyos-http-api-tools). All data validation for application/json requests is done implicitly using Pydantic models/validators; for multipart forms requests, all explicit validation has been moved out of the endpoint function bodies and into the middleware --- this is a pedantic block of code, but allows consolidation and review of all manual checks. An OpenAPI 3.0.2 schema is automatically generated and presented at server-name/docs (Swagger) and server-name/redoc (ReDoc version; slightly more pleasing to the eye).

@jack9603301 It is not a matter of different codes, but rather what python libraries have been provided so far: the focus has been on abstracting the config session, in several directions, and previously there had not been a use case for reading config settings from op mode.

There are two versions that have been developed, reasonably feature complete, pending testing. One presents an OpenAPI schema of application/x-www-form-urlencoded (multipart forms); the other, application/json. The latter uses middleware (strictly speaking, a custom request and route class, instead of the Starlette middleware capability, although that may change) to intercept multipart requests, so as to remain backwards compatible.

https://github.com/vyos/vyos-1x/pull/777

https://github.com/jestabro/vyos-1x/tree/stdout_redirected

Thanks, @erkin --- I'm sure you can cherry-pick from 1.4 to 1.3; 'backporting' is not quite the right word, as it is development branch to stable branch. I really like this solution to the mess that was remote.py.

Assuming T3356 can be backported to equuleus, this fix will not be needed.

Thanks @rob, it is true that nginx is not redirecting to a non canonical https port. Using the nginx custom https status code 497, this can be added; I will update the template accordingly.

If commit is not initiated from a 'live' session (for example, on boot), then redirected stdout/err should go to a file.