PR: https://github.com/vyos/vyos-1x/pull/5284
Suggested CLI and details in PR.

Phase 1 + Phase 2 (evaluate) progress — 2026-06-19:

A workaround to using a custom private registry is to manually preload the images.

https://github.com/vyos/vyos-1x/pull/5283

'Resolved for the rolling

Cannot reproduce on version 2026.06.16-1247-rolling

Jun 19 10:10:41 vyos dhclient[1840]: DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 12
Jun 19 10:10:50 vyos vyos-configd[738]: Received message: {"type": "init"}
Jun 19 10:10:50 vyos vyos-configd[738]: config session pid is 2765
Jun 19 10:10:50 vyos vyos-configd[738]: config session sudo_user is vyos
Jun 19 10:10:50 vyos vyos-configd[738]: commit_scripts: ['vpn_ipsec']
Jun 19 10:10:50 vyos vyos-configd[738]: Received message: {"type": "node", "last": true, "data": "/usr/libexec/vyos/conf_mode/vpn_ipsec.py"}
Jun 19 10:10:50 vyos systemd[1]: Reloading strongSwan IPsec IKEv1/IKEv2 daemon using swanctl...
Jun 19 10:10:50 vyos charon-systemd[3326]: loaded 0 entries for attr plugin configuration
Jun 19 10:10:50 vyos charon-systemd[3326]: loaded 0 RADIUS server configurations
Jun 19 10:10:50 vyos charon-systemd[3326]: loaded IKE shared key with id 'ike-VPP' for: '192.0.2.1', '192.0.2.2'
Jun 19 10:10:50 vyos charon-systemd[3326]: updated vici connection: VPP
Jun 19 10:10:50 vyos swanctl[3857]: loaded ike secret 'ike-VPP'
Jun 19 10:10:50 vyos swanctl[3857]: no authorities found, 0 unloaded
Jun 19 10:10:50 vyos swanctl[3857]: no pools found, 0 unloaded
Jun 19 10:10:50 vyos swanctl[3857]: loaded connection 'VPP'
Jun 19 10:10:50 vyos swanctl[3857]: successfully loaded 1 connections, 0 unloaded
Jun 19 10:10:50 vyos systemd[1]: Reloaded strongSwan IPsec IKEv1/IKEv2 daemon using swanctl.
Jun 19 10:10:50 vyos vyos-configd[738]: [vpn_ipsec]
Jun 19 10:10:50 vyos vyos-configd[738]: scripts_called: ['vpn_ipsec']
Jun 19 10:10:50 vyos vyos-configd[738]: Sending reply: SUCCESS with output
Jun 19 10:10:50 vyos systemd[1]: opt-vyatta-config-tmp-new_config_2765.mount: Deactivated successfully.
Jun 19 10:10:52 vyos commit[3904]: Successful change to active configuration by user vyos on /dev/ttyS0

Taking over from @Vijayakumar and re-scoping. Research outcome: Mergify cannot run content scanners (it only gates on *existing* check results), so the path forward is fleet-wide-capable enforcement via a GitHub repository ruleset ("require workflows to pass") — no per-repo caller files — piloted on vyos-1x / vyos-build / vyatta-cfg-system / vyconf (branches rolling/circinus/sagitta) in evaluate → active mode, with a rebuilt standalone typos.yml (official crate-ci/typos action, prebuilt binary, fork-safe on: pull_request, full-tree scan, central _typos.toml allowlist). The per-repo-caller rollout (stalled ~2 months at 1 repo) is superseded.

https://github.com/vyos/vyos.vyos/pull/486

I was able to achieve the PCP set with different CoS value with subsystem tc of linux. Re-using the available options of QoS, it is possible to identify CoS values (L2 traffic) for ingress and egress. Let me explain how Linux performs the PCP values.

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

https://github.com/vyos/vyos-1x/pull/5281

Status check 2026-06-18 (triage of open GitHub Infrastructure tasks). @Vijayakumar — current state of this rollout:

Resolving — superseded by T8782 (IS-432, Passed). The centralization goal (eliminate per-repo Mergify-config duplication via extends; future policy changes = 2 PRs not 30+) is delivered fleet-wide — but via dedicated vyos/mergify + VyOS-Networks/mergify repos with extends: mergify, not this task's extends: .github design (the bare mergify repo name was chosen for fleet symmetry, and .github-repo hosting was dropped). Live on ~55 product repos; fleet extends adoption tracked/closed under T8852. No per-repo config duplication remains. Closing as resolved (delivered via sibling); Jira companion IS-404 being cancelled as superseded by IS-432.

Fix merged to rolling in vyos-documentation#2108 (Phase 0 CodeRabbit clean on the diff; root cause + fix verified in-browser).

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

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

https://github.com/vyos/vyos-1x/pull/5276

https://github.com/vyos/vyos-1x/pull/5277

HttpC.download() in python/vyos/remote.py always sends a HEAD request before GET to discover redirects and Content-Length. Some remote APIs (notably AbuseIPDB blocklist endpoints) reject HEAD with 405 Method Not Allowed while GET works fine. vyos-domain-resolver catches the failure and falls back to the cached list file — which on first commit is an empty placeholder — so remote-groups stay at 0 members.

Looks like I'll have to use a workaround and run BGP between the two VRFs instead.

In my previous deployments using FRR on Debian, I never had to rely on a full FRR reload for routine BGP policy changes. In most cases, applying the change and performing a soft refresh (for example, clear ip bgp vrf test * soft in/out) was sufficient and did not impact forwarding.

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

FRR reloads the whole configuration per commit, not only one protocol
So policy-route-map is related to FRR config and prefix-lists are the same between all FRR routing daemons.
https://github.com/vyos/vyos-1x/blob/c2f87f243a1f813fbdd319b1004fd3a26397ab3e/python/vyos/frrender.py#L850

This task is covered by https://github.com/vyos/vyos.vyos/pull/438