BIRD Testing With Ansible?

[Alexander Zubkov]

Hi,

>From my point of view it is somewhat orthogonal things. For me Ansible
is more like a deploy tool, not testing. And probably for creating a
testing setup with Ansible you need some additional tools to support
creating of the environment.

> (1) Are you using Ansible with BIRD?

We use ansible with bird, but there is nothing bird-specific in it. We
just generate configs from templates and deploy them with Ansible.

> (2) Do you have some testing setup implemented with Ansible?

For testing with Ansible, I think I would need to create a test
envorinment by some means and Ansbile would only be used to deploy the
configs to it. So no, we do not have testing implemented with Ansible.

> (3) Would you run the upstream functionality tests if they used Ansible?

I do not actually understant what is it about. :)

> (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?

I think if there are examples of other similar test nearby, there is
not much difference.

On Wed, Jun 1, 2022 at 11:44 AM Maria Matejka <maria.matejka at nic.cz> 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