You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To support resilient BGP peers, separate celery and exabgp to operate in different containers. This involves developing a way for celery to remote-trigger an exabgp config refresh in one or more remote containers.
The text was updated successfully, but these errors were encountered:
new PROXY_CLASS, proxy_exabgp_remote, in install script, settings_local.py and proxy.py
new proxy, utils/proxy_exabgp_remote.py which has method Applier.apply()
all this proxy does is make a straightforward HTTP call to every configured exabgp container, with no params
exabgp containers run a small HTTP server to accept these calls
new view in gunicorn, which provides up to date exabgp config file
on trigger, HTTP servers fetch this file and send a SIGUSR1 to the local exabgp
In production, there's a good chance that even if FoD is running in containers, the exabgp instances will be on separate VMs. Since Celery needs to be configured with the addr of all exaBGP servers, and the number could vary, this is prob something to configure manually in, e.g. flowspy/settings_peering.py? That would also in principle give gunicorn enough information to provide a complete exaBGP config, including AS numbers etc, to each exaBGP server.
For development, every individual exabgp container will further need to be specified in docker-compose.conf. Pass in env variables with their peering info.
To support resilient BGP peers, separate celery and exabgp to operate in different containers. This involves developing a way for celery to remote-trigger an exabgp config refresh in one or more remote containers.
The text was updated successfully, but these errors were encountered: