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.

@pasik I should have a fix committed soon; thanks for the report !

This actually has nothing to do with the http api, but rather is a deadlock coming from ConfigSession show_config(), namely, the use of Popen.wait() in __run_command().

Currently, vyos-configd will explicitly report ConfigError to the console; however, non-fatal warnings or information will not be reported. An example of a non-fatal warning is:

@Viacheslav , good point, and unfortunately, that's not an exact science: cf. T2252, wherein the timeout was raised to 10 minutes, the time of the timeout reported above.

@pasik this is not a known issue, and your report is much appreciated. I have not drilled down into the problem yet; any debugging that you have a chance to do is welcome !

Yes, I very much like this, and is what I am imaging with 3., above.

@c-po this is an excellent idea, and a useful reference for the bracket notation; this will need a bit of design of how best to slice the problem:

1. keeping key_mangling but excluding on tag nodes
2. removing key_mangling completely
3. removing on a case by case basis with the existing argument to get_config_dict()

This remains open; need to rejoin discussion.

PR https://github.com/vyos/vyos-1x/pull/692

Will remove test case and rebase to create PR and merge for 1.4; will later backport to 1.3 pending any issue.

Two minor comments left out of the above:
(1) The script in question runs a check on all interface definitions, however, there is no measurable increase in compile time.
(2) lxml will escape characters '>', '<', however these are unescaped by build-command-templates, so the issue is mooted. One can see the single line changed in the XML by running the test case above; it is noted that some interface definitions already have a mixed use of, say, '>' and '&gt;'.

Preprocessing solution in testing here:
https://github.com/vyos/vyos-1x/compare/current...jestabro:override-default

@c-po has also tested an iso from the above branches, notably testing a vyatta-wanloadbalance configuration. It had been presumed that the listed dependency of vyatta-wanloadbalance on vyatta-config-migrate was a legacy error, as there were no explicit dependencies, but it required a sanity check. I will merge via PR's, in order to better track the changes over the 3 required packages.

Allowing utf-8 in general may be problematical:
(1) utf-8 within, say, a description name (see parent T2941) should be manageable; any restrictions in the legacy backend (I have not confirmed) could be addressed relatively easily
(2) allowing alternative quote characters (this task) is a can of worms for the lexer, and likely a very bad idea

If you look at vif 17, the description contains matched single quotes: notably, unicode character U+2018 'Left Single Quotation Mark'. Converting to utf-8 following the prescription in 'man utf-8' gives:
0xE2 0x80 0x98
hence the 0xE2 error message. One can reference this at
https://www.compart.com/en/unicode/U+2018, but this value was checked for completeness.

vyatta-config-migrate removed in branches referenced in:
T3161 Consider removing ConfigLoad.pm
In testing.

Changes in branches here:
https://github.com/vyos/vyatta-cfg/compare/current...jestabro:T3161
https://github.com/vyos/vyatta-cfg-system/compare/current...jestabro:T3161
https://github.com/vyos/vyatta-wanloadbalance/compare/current...jestabro:T3161
This will need reasonable testing before commit, although all pieces had previously been implemented

Taras confirms that the functionality of

vyatta-cfg-system/etc/init.d/ec2-vyos-init

is replaced by that of cloud-init tools, so this legacy invocation will be removed, allowing for the removal of ConfigLoad.pm, since the other scripts have already been rewritten.

This was discussed briefly in last week's meeting: we would like to drop this package, however, the problem remains that the two scripts in vyatta-cfg-system

See subtask T3082 for origin and details of this issue.

As discussed in Slack channel, these leftover processes should be cleaned up the next time configuration mode is entered (by UnionfsCstore::setupSession). In my limited testing, I can reproduce the leftover processes as above, but they are cleaned up the next time I enter config mode. There may well be corner cases where this mechanism is not successful, but I have not reproduced.