Firstly, this bug should be fixed T5837

@zsdc Can we close it?

It won't fix due the old backend
Fixed in 1.4/1.5

We agree not to use raw options anymore.
If some options are required, it should be a separate PR per configured option.

Most of the changes are not supported by reload accel-cmd/systemctl unit.
Accel-ppp cannot apply some features/changes without the daemon restarting. In other words, there are only several features that could be applied by reload.

The current FRR 7.5
There are no reports with this bug.
Close it. Re-open if you still have issues or create a new bug report.

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

In T5775#168092, @marvin wrote:

Excellent; thanks @GurliGebis! I built 1.4 today and confirmed it's working as expected.

As far as I'm concerned, this issue is now resolved and the ticket can now be closed.

Excellent; thanks @GurliGebis! I built 1.4 today and confirmed it's working as expected.

Yes it should trigger to recreate container but it doesn’t get a dictionary key for recreating

In my case, the container is created and running using IPv4 only. The network it is in has a defined prefix for IPv4 and IPv6. Then, the only thing I try to do is add an IPv6 address to the container. The network it is connected to already has the IPv6 prefix defined. That is when it dies.

The mentioned file that missing is located upstream in https://github.com/miniupnp/miniupnp/tree/miniupnpd_2_3_1/miniupnpd/netfilter_nft/scripts
and the upstream configuration options that we think are missing to match vyos chains is https://github.com/miniupnp/miniupnp/blob/miniupnpd_2_3_1/miniupnpd/miniupnpd.conf#L77

Could you point out some documentation/examples on which scripts are missing?
It seems it has never been tested since @jack9603301 implemented it in task T3420. It seems he also didn't test it.

Adding a new container with both addresses and networks in one commit works fine.

set container name alp01 image 'alpine'
set container name alp01 network NET01 address '10.0.0.12'
set container name alp01 network NET01 address '2001:db8::12'
set container network NET01 prefix '10.0.0.0/24'
set container network NET01 prefix '2001:db8::/64'

We don't use /usr/libexec/vyos/validate-value.py anymore
There should be a separates tasks if required.

There is nothing to do there, all checks for linter Jinja included to vyos-build.
Close it.

It was changed for 1.4/1.5 and won't be changed for 1.3 LTS (old backend)
If someone wants it for 1.3

set protocols bgp 65001 parameters default no-ipv4-unicast

We are using sshguard

set service ssh dynamic-protection

@thomas-mangin Do you have a PoC?

Comparing boot time for now 1.3 and 1.1.8 is not actual
There are 2 different systems :)
Also, some validators were rewritten on 1.2 to Python and for 1.3 to sh, OCAML and so on (python validators could be cause of the issue)
In my internal test VM loads ~40 sec tested in VyOS 1.3.5
We always can improve something, but lets find what we can improve in separate tasks.

@mb300sd could you re-check?

The main issue is synchronization between all routing daemons and zebra, especially with "policy".
So you are getting strange things like a policy configured for zebra but the same policy not exists/applied for other daemons.
It is impossible to integrate it the correct way.
Reopen for 1.5, 2.0 if required and if it will be possible in the future with correct syncing between all daemons.

We can't do more due to old backend on the 1.3
If there will be a specific options to improve it should be a separate task
Close it.

Refactored in 1.4/1.5
Let's avoid the firewall migrations for the stable branch.

It won't be implemented for 1.3

Configs weren't provided, so closed the task as invalid. Works with internal tetts.
Re-open it or add steps to reproduce.

Implemented in 1.4
Wontfix for 1.3 due to old backend.

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

/config/dhcp4.leases ownership seem to change when migrating to latest 1.5-rolling-202312171632

Forgot to ever reply to this - I just wanted it added as a standard debian package so that scripts that depend on it can have it available without needing to be installed seperately.

Think this can be closed - there's no such command in 1.3 is there?