Repository navigation
F #-: VRouter: run hooks on VRRP role changes - #405
Closed
netaviator wants to merge 1 commit into
Closed
netaviator wants to merge 1 commit into
netaviator wants to merge 1 commit into
Conversation
Run the executables in /etc/one-appliance/ha-hooks.d/ in name order with "up" (the node became MASTER) or "down" (it became BACKUP) once the stock failover services have been switched. Other services (a routing daemon, for example) can follow the VRRP role without patching the Failover module. A hook never breaks the failover: every failure is only logged. Each hook runs synchronously but bounded: its output goes to a file (not a pipe, so leftover children cannot block the failover) and a hook past 30s is killed together with its whole process group. Add the first unit tests for the Failover module (event handling and the hooks: order, arguments, non-executable files, failing, hanging and raising hooks). Signed-off-by: Jan Gilla <jgilla@level66.network>
netaviator
added a commit
to netaviator/one-apps
that referenced
this pull request
Oct 20, 2026
…tributes The VRouter cannot talk to upstream routers dynamically. Add an FRR module that runs bgpd, ospfd and bfdd next to the existing services and builds /etc/frr/frr.conf from attributes. Nothing changes unless it is turned on. The attributes come from the VM context at boot (ONEAPP_VNF_BGP_*, ONEAPP_VNF_OSPF_*, ONEAPP_VNF_FRR_ROUTER_ID, ONEAPP_VNF_STATIC_ROUTES) and, while the VM runs, from the VM user template through OneGate. A change is checked with frr-reload.py --test and then loaded with --reload, so other neighbors keep their sessions. If the reload fails, the last good config is loaded again. A failed apply is retried with a growing delay. BGP has IPv4 and IPv6 neighbors with password, BFD, prefix filters, local pref, MED and prepend. OSPF is OSPFv2 with area, cost, passive, timers, MD5 key and BFD per interface, an optional default route and redistribution of connected and static routes. On the VRRP backup, BGP gets a longer AS path and a higher MED, and OSPF a higher cost and metric, so peers prefer the master. This needs the failover hooks (OpenNebula#405). The backup settings are switched by a hook in /etc/one-appliance/ha-hooks.d, which Failover has to call. Without OpenNebula#405 the hook is installed but never run, and both nodes stay on the master settings. The service template is not part of this. The marketplace template needs an input for each attribute it should offer; the README lists them. There is no limit on the number of neighbors or OSPF interfaces in the module. Checked with 483 unit specs, 28 of which compare the generated frr.conf with stored files, and with real FRR 10.2.1 in Docker (sessions, filters, live changes, rollback, the backup settings, OSPF, install and configure on Alpine). It was also tested live on VMs with several instances and external peering. Signed-off-by: Jan Gilla <jgilla@level66.network>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Run the executables in /etc/one-appliance/ha-hooks.d/ in name order with "up" (the node became MASTER) or "down" (it became BACKUP) once the stock failover services have been switched.
Other services (a routing daemon, for example) can follow the VRRP role without patching the Failover module. A hook never breaks the failover: every failure is only logged. Each hook runs synchronously but bounded: its output goes to a file (not a pipe, so leftover children cannot block the failover) and a hook past 30s is killed together with its whole process group.
Add the first unit tests for the Failover module (event handling and the hooks: order, arguments, non-executable files, failing, hanging and raising hooks).