Ahoj Maria!
For our production RS'es we do not use Ansible, yet we do for Restena
route collector machine which runs on a Centos custom build and what we
have done with Ansible is :
. Building the bird config
. Install bird2
. Ensure bird2 config folder exists . Remove old configs
. Configure bird2
. Ensure bird2 is running and enabled
Also we have used Ansible to deploy bird_exporter : . Installing the
systemd service . Building its config and so on.
I would be very glad to have soon bird officially being Ansible'd .
Regards, See you soon
Irene,
On 01/06/2022 11:37, Maria Matejka wrote:
TL;DR: Should we test BIRD with Ansible?
Hello!
Dear fellow users and anybody else reading this message, please take a
deep breath and read the story of testing BIRD before you shout NO,
YES, DEFINITELY MAYBE or whatever else.
Long time ago, when Linux implemented Network Namespaces feature, even
before anybody knew anything about "ip netns", Santiago created a
simple but quite powerful tool called "netlab" to test BIRD on one
machine, using this exact feature. It has grown to quite a decent set
of automatic functionality tests which you can see in the bird-tools
repository[1] in the "netlab" directory.
After some time, when I got to BIRD development, we wanted to test
also BIRD on different platforms. We went to virtualization, setup a
decent testing setup with QEMU-KVM and OpenVSwitch and then I tried to
run there a simple MPLS setup when the OpenVSwitch suddenly crashed on
SegFault. I solved it by using just plain old bridges and veth's.
When I met some friends several days later, one of them being a Linux
kernel developer working also on OpenVSwitch, I mentioned these
problems, thinking that he may give me a pointer how to solve it.
Instead, he interrupted me, saying "hey, shut up, this is an embargoed
bug". I had missed that this segfault may be a security problem
leading at least to DoS.
This was happening when the OpenStack and LibVirt and others were
still in an early phase of development and we couldn't find any
suitable solution for us so we just developed something for ourselves.
Anyway, now it is 2022 and when I reach out to almost any user of
BIRD, I hear about Ansible. I'm thinking whether it is a good idea to
leave our old tooling in a museum and to migrate to Ansible.
Facts:
* Our team is familiar with the current tooling, not Ansible.
* It's probably easier to learn how to use our tooling than Ansible,
provided you have seen neither of them before.
* Some of the users are already using BIRD with Ansible.
* We don't know much about pros and cons of Ansible.
Proposal:
We would retire our old testing setups and instead of that we would
upstream a bunch of functionality tests implemented in Ansible.
I have some questions for you:
(1) Are you using Ansible with BIRD?
(2) Do you have some testing setup implemented with Ansible?
(3) Would you run the upstream functionality tests if they used Ansible?
(4) If encountering a bug, would you consider creating an Ansible
scenario to replicate that behavior?
(5) If contributing, would it be OK for you to create also an
appropriate functionality test in Ansible, or rather in our current
tooling?
Thank you all for your answers and discussion, please don't throw
chairs nor eggs nor tomatoes on each other.
Maria
--
Irene Lalioti
Network Engineer
Fondation RESTENA
2, avenue de l'Université
L-4365 Esch/Alzette
Tel: +352 424409 1
Fax: +352 422473
This email may contain information for limited distribution only, please treat
accordingly.
BEGIN:VCARD
VERSION:4.0
FN:Irene Lalioti
N:Lalioti;Irene;;;
TEL;VALUE=TEXT:Network Engineer
UID:2b720f1d-244b-7845-940a-c9a50d678857
END:VCARD
