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 <[email protected]> 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
