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.

The json file containing the system component version information was previously an artifact of the XML syntaxVersion implementation; with revisions to the latter in place for 1.4, and initial implementation removed for 1.3, the json file will now be dumped during migration.

This will be merged, pending discussion on pros/cons of preprocessing vs. relaxing schema restriction.

A bit of background: the error here is is a result of the Relax-NG schema requiring a leaf node to have a 'properties' entry; that is considered a sanity check by the schema author, but emerges as an issue when we moved to a modular structure for the *.xml.i include files. Leaving that restriction as-is, the solution of merging leaf nodes in the lxml script should be straightforward (the general case more intricate), so I will look at amending the override-default script.

@artooro This sounds reasonable, and I don't imagine a problem, though I have yet to try it; if you would like to submit a pull request with fix, I will review.

A simple experiment using GraphQL to configure a DHCP server is here:
https://github.com/vyos/vyos-1x/compare/current...jestabro:graphql

Already backported: ff7b2b0e62510ef8de28c9c4bfa34badeabec775

@erkin One additional detail: there is an attempt at clean up on entering configuration mode (in UnionfsCstore::setupSession); nonetheless, there are clearly potential (and potentially serious) issues here. Cf. T3054 for the comment on setupSession; there has been no serious investigation of the issue yet.

Draft PRs:
https://github.com/vyos/vyos-utils/pull/1
https://github.com/vyos/vyos-1x/pull/869

Needs testing, but initial implementation here:

Opening a new task for the issue described in the last comment, above. The original problem re. error messages was resolved in vyos-utils 68d1b283 .

There are two separate issues in this task: quoting of hw-id values (resolved in Sagitta/Equuleus); re-ordering of interfaces with respect to hw-id (Open).