@rps this did not make it into 1.3.0, but was discussed recently and will be addressed; it is, as you point out, a regrettable omission in functionality

relaxes the condition to escape non-ascii bytes. Updating the commit id in the Dockerfile and relaxing the ascii restriction in configsource.py will allow unicode chars in config.

This is a mutability issue: since under vyos-configd the script is loaded as module, global variables persist, however:

Utility function added; it remnains to move 'vyos-config-status' to /run.

cf. T3980, also

The plan is to weaken this to a warning in 'verify'; as summarized above, validators are pass/fail and warnings are not an appropriate response for a validator

One detail towards a resolution: if the vyos-http-api-server is started manually (without systemd) then the output is not truncated. If one wants to try this, one should configure 'set service https api' (to update Nginx config appropriately); then 'systemctl stop vyos-http-api'; then, as root:

Thanks, I've confirmed the issue; I should have it resolved soon

This brings up an interesting issue: validate_value.ml could easily be modified to print warnings, while maintaining T2759 (namely, only print fatal errors if _all_ validators fail for a given setting), however, is this reasonable behaviour ? One would think that a 'validator' is either pass or fail, and if it is just giving a warning, it is no longer a validator.

I will take a look; thanks for the report !

@adestis there were discussions on this in the past week --- I will be helping @dmbaturin with the task

Work in progress:
https://github.com/vyos/vyos-1x/compare/current...jestabro:linkstate
https://github.com/vyos/vyos-build/compare/current...jestabro:linkstate

Note that the set commands above have already mangled the name --- no_tag_node_value_mangle is there to preserve names as follows:

A few quick tests would suggest that this is specific to vrrp: though not exhaustive, of course, several examples of setting tag-node values in paths other than vrrp work as expected.

https://github.com/vyos/vyos-1x/pull/1019
https://github.com/vyos/vyatta-cfg/pull/41
https://github.com/vyos/vyatta-cfg-system/pull/171

In testing:
https://github.com/vyos/vyos-1x/compare/current...jestabro:interface-names
https://github.com/vyos/vyatta-cfg/compare/current...jestabro:interface-names
The following removes legacy code: vyatta_net_name, vyatta_interface_rescan, XorpConfigParser
https://github.com/vyos/vyatta-cfg-system/compare/current...jestabro:interface-names

https://github.com/vyos/vyatta-cfg-vpn/pull/48

@stepler on a fresh installation, all migration scripts will be run, as the default config contains no component version string, and has to be incrementally migrated.

I will push to have a solution included in 1.3, reviewing both zsdc's and rps's suggested patches; we will not hold up epa1 for this, but rather include as a bug fix following.

A careful analysis of the error here is provided in the last two comments; the general question of unicode support will be investigated in T3785.

This is resolved for 1.3, and is not a backport candidate for 1.2, as indicated above.

cmd = {"op": "delete", "path": ["protocols","static","route", subnet, "next-hop", nexthop]}

passed via the http-api properly returns the same error message as would be seen on the CLI. Non-issue.

The revisions in T3768/T1950 provide a listing of components in /usr/share/vyos/component-versions.json for easy reference; this file is not used during migration, so any changes to the file will have no effect. The larger issue of dropping reliance on vyatta-cfg-system for component version information will be handled in T3474 for those components that have been moved to XML/Python.

T3785 is opened for the general issue; a workaround will be provided in the interim.