I have started playing around with it.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
May 15 2025
Sorry to respond to such an old ticket but we stumbled over it now with a migration from VyOS 1.3.8 to VyOS 1.4.2.
After rebooting the system seems to have lost the configuration completely because it was not possible to logon to the system on the console anymore.
In the boot screen just a System error was shown.
May 14 2025
Added a merge-request in github: https://github.com/vyos/vyos-1x/pull/4506
This way we will expect the set of commands from both sites to reproduce.
If there will be incorrect config settings as in example you provided, the task will be closed as invalid. We do not provide support via forge and will not say you what to change. There is a forum for these questions.
May 13 2025
With the above merged, the following update will be needed for successful builds:
https://github.com/vyos/libvyosconfig/pull/37
Following that merge, the corresponding update of commit hash for vyos-1x will be required.
A workaround may be to allow the user to set the watchfrr_options in /etc/frr/daemons to add a -T 500 for example for watchfrr to wait 500s before trying to restart bgpd
After waiting more than 1 hour, no config reload happened so i trigged one by removing a unused peer group, it triggered, and as i expected, after almost 3 minutes, it finished without flapping the sessions
PRs:
Hi Viacheslav
I attached config tests and smoketests (the most of routing protocols fail)
May 12 2025
Locking added in PR
https://github.com/vyos/vyos-1x/pull/4505
PR to build the plugin. Added it to the pre build hook, not sure if that's where you guys want it done but it works.
https://github.com/vyos/vyos-build/pull/962
At the moment (during internal tests), some config tests cannot pass:
It looks like a support request, ask on the forum.
May 11 2025
For backport, going to wait for Kea 3.0 at end of Q2. We then won't need to any manual patches.
May 10 2025
May 9 2025
@Viacheslav,
default must have the same ipv4 subnet of "podman" default network, if changed, Podman doesn't detect it (via conf-mode commands).
@covalente, should we disable the name default? Or do you have another idea?
After further debugging, it's the network name that causes the issue with CNI creation (pod-*) and static ip.
Podman overlaps "podman" default network and the user-defined "default" network.
containers get assigned to "podman" default network and CNIs ignored, so causing this primary issue.
@covalente Add a simple set of commands to reproduce, thanks!
May 8 2025
It looks more like a support request, ask on the forum.