BIRD Testing With Ansible?

[Irene Lalioti]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: irene_lalioti.vcf
Type: text/vcard
Size: 150 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220602/caffba7b/attachment.vcf>