if the interface gets delete from the config, the wg device gets deleted from the OS and all its routes

This is exactly the reason why "set protocols static ..." commands use zebra instead of pushing routes directly to the kernel with iproute2. Zebra takes care of interfaces going up and down and reinstalls the routes when needed.

Now, is that suppose to happen automatically ( i can include it in the wireguard.py script), or is it supposed to be setup via 'set static proto ...'? What would be the better way?

If wireguard cannot create routes on its own, I believe we should leave route setup to the user. Doing it automatically when it's not actually supported is a very leaky abstraction.

Works now, though I need to discuss the pull requests with PPP maintainers.

Should be working now.

I believe I've fixed it, though feedback won't harm.

Closing for now then, let's reopen if needed, or make a separate task for bridging openvpn with new interface types.

@mb300sd The reason we do not allo arbitrary names is that there's no easy way to find out exact interface type, so we forced them to begin with eth, br, tun etc. so that scripts can find out what it is and filter only compatible interfaces.
Relaxing the requirements to "starts with keyword" like eth-lan or tun-office would be an interesting idea, but I'm afraid only in the long run, since a number of scripts have regexes like eth\d+ hardcoded in them and it will take time to clean up.

The renderer works now (for a long time already, even), so it's time to close this task finally. ;)

@UnicronNL @hagbard Please do not use that package! I've inspected it, and it's below any reasonable standards!

One note: I'm removing the "firewall" option. First, it's only relevant for RFC-compliant VRRP, and there's no checking for it. Second, it has no advantages over assigning the firewall directly to the parent interface in any case.
Third, it was implemented inconsistently: ethernet VIFs and non-ethernet interfaces (e.g. bond) lack it.

For the reference: https://github.com/acassen/keepalived/blob/master/doc/NOTE_vrrp_vmac.txt

Does the problem also exist with the other kind of VRRP?

I'd need to check.

There was one or two 1.2.0 images that did have a hostname problem due to a problem in the new implementation of the system host-name command, but I fixed it. I wonder if your problem might be carried over from one of those images.

Could you try updating some test machine from 1.1.8?

You get this when you upgrade from a previous rolling release, or from 1.1.8? If the former, which one?

Should we delete user home dirs when deleting a user then?

I think new version should still be able to sync with the old versions, since people will be upgrading routers in their HA pairs one by one, and loss of functionality during upgrades isn't a very nice situation.

@hagbard Migration scripts are no longer that much of a problem (though they still need to be carefully written). See http://blog.vyos.net/writing-migration-scripts-and-manipulating-vyos-config-files-outside-vyos-just-got-easier

https://github.com/vyos/vyos-1x/blob/new-vrrp/interface-definitions/vrrp.xml The new syntax draft.

That's my punishment for the sin of only testing op mode commands from conf mode.