network collection use case

[pabelanger]

Greeting!

The ansible network team has a significant amount of integration testing today against ansible/ansible. This is mostly driven via zuul.ansible.com and ansible-test.

Today we test the following versions of network appliances:

• arista.eos
• cisco.ios
• cisco.iosxr
• cisco.nxos
• juniper.junos
• vyos.vyo

Across the following versions of python:

• python27
• python35
• python36
• python37
• python38

The ability for us to do integration testing against appliances, is all driven via the fact that nodepool (zuul) has the ability to provision our appliances in a testing environment. There is a large amount of code and effort in place to make this happen.

Before migrating to the community collection_migration tool, we wrote a large amount of automation that does the following:

• clone ansible/ansible
• run migration script to production ansible_collections.arista.eos
• propose a PR against http://github.com/ansible-network/ansible_collections.arista.eos
• Run lint testing, collection tarball builds, and 5 integration tests

We only then merge the PR created by the migration tool, if all testing has passed. We then, repeat this process, each time content in ansible/ansible changes, to preform the sync to each ansible collection.

Why we do this, is we cannot migrate all our content at once (I mean we could, but the state would be broken). So what we have agreed to, is to keep tests running against ansible/ansible, then run the same tests against the collection produced in ansible_collections.arista.eos. If we can show that both sides of testing are passing, and the same results, then we have a high level of confidence that our new collections will not break. We then can decided when to migrate all 7 network collections outside of ansible/ansible and delete code.

This all depends on the idea, that we continuously deploy migration using the migration script. This also allows us to provide a layer of smoke testing, to help ensure other collections will be migrated correctly.

This means, we would like to avoid, a one time migration, then manually make changes to our collection. As the amount of effort required to keep ansible/ansible in sync and 7 collections would be too much work for humans. It would also could mean large amounts of work to bring testing back into compliance.

Hopefully that explains our use case, and happy to dive more into the details.

[bcoca]

are you using this migrate.py to create the migration? if so, it is not designed for your needs, if not .. unsure what this has to do with the script.

[pabelanger]

yes, we use migrate.py to create both ansible-minimal and each network collection, continuously building / deploying. We had our own migration script in the past, but opted to move to the community one to standardize.

The key is, we have a hard requirement on keeping testing in ansible/ansible devel passing and new collection passing before we delete content in ansible/ansible. This way, once we delete content in ansible/ansible, we know our network collections just work.

[bcoca]

@pabelanger understood, but that is not what THIS migration is designed to do and I don't think our goals will align in the end.