On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess <mysidia@gmail.com> wrote:
Running the BGP application in a container on a shared storage system managed by a host cluster would also make it easier to start the service up on a different host when the first host fails or requires maintenance.
On the other hand, running directly on a host, suggests that individual hosts need to be backed up again, and some sort of manual restore of local files from the lost host will be required to copy the non-containerized application to a new host.
Even if the BGP speaker is running right on the host, the shared storage or backups thing doesn't click for me. What about your BGP speaker will need persistent storage? At least in our environment, everything unique about the BGP speaker is config injected at startup or can be derived at startup. This might be based on differences in how we're using them (BGP daemon per container host in our case, rather than "I need X number of BGP speakers; schedule them somewhere"), I guess. -- Hugo Slabbert | email, xmpp/jabber: hugo@slabnet.com pgp key: B178313E | also on Signal