not willing to take the lead on this task but happy to help.

@jestabro could you please clarify how interfaces-tunnel.py is not following the guideline. The class it uses to generate the dict is internal to the get_config() function and the dict API is respected.

Possibly related to T2205, it might have been fixed since this was reported.

Apparently the "still in use" check logic really leaves much to be desired. See T1292. I wonder if there's a general fix within the current approach.

That part is rewritten in current already. https://github.com/vyos/vyos-1x/blob/current/op-mode-definitions/show-log.xml#L212

Going to mention this in here:

@dmbaturin sure, PR https://github.com/vyos/vyatta-cfg-firewall/pull/17

Turns out it's because the conf mode "allowed: " is escaped and eval'd when it's passed to the shell: https://github.com/vyos/vyatta-cfg/blob/current/src/cstore/cstore.cpp#L756-L762

Could you make a pull request?

I've reviewed the code and it looks good to me.

The root cause was insufficient validation.

Whichever decision we make, let's not change this in 1.3—there are lots of changes already.

This rabbit hole goes deep. It's not just a display issue, but the whole reason we cannot have rollbacks without reboots—there's no way to generate an inverse changeset "thanks" to this.

This task will be resolved by removing Interface.pm altogether.

Glad to hear that!

Sorry it took so long! I've cherry-picked it into crux, will be in 1.2.6.

Ideally we may want to add an extended "if VRRP configured" check, or make keepalived produce an empty (or special) file when it's running but has no data. For now this fix should do though.

VTI is secretly IPIP, so it doesn't support IPv6. The real issue is that we don't support the IPv6 variant of VTI yet.

The user-data dir actually is preserved on upgrade, it's just the check that is faulty. Need to look into it.

Added a warning.

It may be a good idea, but it sure needs a serious and broad discussion. I'm moving it to 1.4 for now, though we may move it back if we have time before the freeze.

Since we are heading towards a freeze, I believe it's better to live big changes for later, even though I don't categorically disagree with the idea.

Still reproducible in 1.3-rolling-202006241940

Now that we have an HTTP API, I believe it's time to deprecate vymgmt altogether.

I have checked and fixed bandwidth default units for Limiter, Network Emulator, Rate Control,
Shaper and Shaper HFSC.

vif interfaces are removed normally.

In T2630#68490, @Asteroza wrote:

There is the weird area here, as 1G interfaces are generally capped at 9K more or less (whether limits include those overheads or not is always weird, such as switches saying they are 9K but also 9120). For VM nics, you're never completely sure of what the host or what the switches directly connected to the hosts will allow either.

Maybe warn on over 9000 but not block it? Also, what are NVMeoF/RoCE NIC's saying these days? Still, since path MTU discovery isn't reliable, direct testing the interface seems like a good fallback, but while udev running it might be okay, again for VM nics, the host changing the underlying hardware could cause changes while running, so rescan on every commit?

Update: After hooking up an actual EZIO device to my VM and working the code back and forth, I seem to have settled on this design:

It looks like this bug is in the kernel.
1.2.5 - 4.19.106-amd64

Work as expected.

The problem also probably exists with vif_s .. it needs to be investigated.

https://github.com/vyos/vyos-1x/pull/474/files