DevOps workflow for networking
alumbis at gmail.com
Fri Aug 18 18:08:01 UTC 2017
I gave a presentation on CI/CD for networking last year at the Interop
conference; my demo was based on Gitlab
I use Behave for testing, but it is just a front end for python code under
the hood to actually validate that everything is doing what it's supposed
to be doing.
I did a little bit of work to try and get Ansible to do checking and
validation in a playbook, but since Ansible isn't really a programming
language it felt like putting a square peg in a round hole. I would
recommend an actual programming language or testing frame work.
Likely the biggest challenge you'll encounter is a lack of features in
vendor VMs and the fact you can't change interface names. Generally, in
production, we don't have "eth1, eth2, eth3" as the cabled up interfaces,
so you end up needing to maintain two sets of configs (prod and test) or
something to modify production configs on the fly, both of which are crummy
>From a workflow perspective, you can treat configuration like code and run
full test suites when pull requests are issued and then use the test
results as the basis for a change review meeting. Don't let humans talk
about changes that we already know won't work.
Glad to hear about other people seriously considering CI/CD in the network
space, good luck!
On Wed, Aug 9, 2017 at 8:52 PM, Kasper Adel <karim.adel at gmail.com> wrote:
> We are pretty new to those new-age network orchestrators and automation,
> I am curious to ask what everyone is the community is doing? sorry for such
> a long and broad question.
> What is your workflow? What tools are your teams using? What is working
> what is not? What do you really like and what do you need to improve? How
> mature do you think your process is? etc etc
> Wanted to ask and see what approaches the many different teams here are
> We are going to start working from a GitLab based workflow.
> Projects are created, issues entered and developed with a gitflow branching
> GitLab CI pipelines run package loadings and run tests inside a lab.
> Tests are usually python unit tests that are run to do both functional and
> service creation, modification and removal tests.
> For unit testing we typically use python libraries to open transactions to
> do the service modifications (along with functional tests) against physical
> lab devices.
> For our prod deployment we leverage 'push on green' and gating to push
> package changes to prod devices.
More information about the NANOG