Hey all,
I have been doing a lot of work with the API, in particular building a “configuration state manager”. The intention is to write in a generic way code that will take a config (an export file) and compare it to a running config, show the differences and make whatever changes are required to bring the running config to the desired config. However I have come up with a couple of limitations in the API some of which are also limitations in the CLI.
- I would like to see is a field added to every config line that is a customisable id, just a number that does absolutely nothing to the actual config but is reported back in a print or export. I realise that this could be done with a #tag in the comment, however this would be cleaner. This would allow people to give config lines an id, given it is just numeric it would be easy to index and find quickly.
- I would like to find a way of seperating out the read-only fields from the settable fields in the API. If do a print in the API and it gives all the fields some of which are default settings, some of which are changed from the default (or obligatory required fields), some of which are read-only status settings. However I cannot in a generic way figure out which is which. I can see three solutions to this: the first is to allow “export” and “export verbose” as commands in the API, since they only output settable fields. The second is to change the names of the read-only fields in a standard way (like prefixing them with a character like ‘_’) - however this would break a lot of existing scripts. The third is allow us through the API to pull a “dictionary” that describes in a generic way each field and its default. I am thinking that a API command such as /ip/firewall/filter/dict would pull a list of the fields with values that describe what can be done with them. Each line could be field with “field=name”, “type=(boolean, numeric, ipv4, ipv6, string, enum)”, “enumlist=”, “readonly=true|false”, “required=true|false”, “description=”, “default=”.
- There seems to be confusion between the API and the CLI about the values for boolean: is it “yes” and “no” (CLI) or “true” and “false” (API). It would make sense to bring these together (pick one but allow both)
- When setting a field to its default value sometimes you set it to the default value (typically “”), sometimes you do !field, it would be nice if !field would always set it to its default value.
- There are lines in the config that cannot be removed, such as in /interface/ethernet or also /queue/type where some can and some cannot. It would be good to reliably identify those lines that cannot be removed (only updated) with a field name. Sometimes you can use the “default” boolean for this, but not always.
- The field “dynamic” config lines are wierd to search for. If you want to avoid them, sometimes you have to use !dynamic, sometimes dynamic=no
- It would be great if we have a way to invoke safe mode in the API. This could be done in a similar way to the CLI method with an API command to take and release it. Even better would be during safe mode an automatic abort on any errors and return to the original config.
There are more things that could be done to make the config easier to parse and process, but I would be interested in people’s thoughts.