some observations below:

> On 9 Aug 2017, at 21:52, Kasper Adel <> wrote:
> We are pretty new to those new-age network orchestrators and automation,

There are definitely many options out there.  With a considerable amount of 
sophisticated.  But fortunately, it is possible to start simple and add layers 
of abstraction as knowledge and experience is gained.

> I am curious to ask what everyone is the community is doing? sorry for such
> a long and broad question.

the brief version:  we are working towards integrating a SaltStack with Napalm 
management and orchestration solution.

> 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

Things are getting started.  I am able to automate the build of servers simply 
by knowing the mac address and then pxebooting the device.  The operating 
system is installed, auto - reboote.  It then automatically gets its total 
configuration applied , again automatically, from a Salt server.

Our operating environment uses Debian.  And by incorporating the auto 
installation of Quagga/FRR, Openvswitch, KVM/Qemu, and LXC into the appropriate 
devices, it is possible to build a homogenous 
server/router/switch/virtualization solution with certain devices picking up 
varying weights of those roles.

The people on this list who are running high bandwidth networks, may not see 
this a much of a benefit, but for smaller operators, I thinks there is value.

But then again, when something like Napalm is incorporated into the mix, then 
automation of the ‘big iron’ becomes part of the overall solution.  I came 
across a CloudFlare slide deck which shows their perspective for management, 
implementation, and orchestration.

And SaltStack has a proxy minion, which enables it to talk to cli based devices.

> Wanted to ask and see what approaches the many different teams here are
> taking!
> We are going to start working from a GitLab based workflow.

Salt uses generic ‘state’ files which are completed with device specific 
settings from ‘pillar’ files.  Both of which can be version controlled in git.

> Projects are created, issues entered and developed with a gitflow branching
> strategy.
> GitLab CI pipelines run package loadings and run tests inside a lab.

I not affiliated with SaltStack, just a happy user.  Having said that, various 
dev/test/prod scenarios can be implemented.  With orchestrated work flows and 
provisioning processes based upon the level of sophistication required.

> Tests are usually python unit tests that are run to do both functional and
> service creation, modification and removal tests.

Rather than re-inventing the wheel, take a look at SaltStack or Ansible and/or 
Napalm.  All are python based and could probably get you to your target faster 
than when using Python natively.  When it is necessary to go native python on a 
hairy integration problem, then it is no problem to incorporate Python as 

> For unit testing we typically use python libraries to open transactions to
> do the service modifications (along with functional tests) against physical
> lab devices.

Napalm may get you that next level of sophistication where configs can be 
diff’d before roll-out.

> For our prod deployment we leverage 'push on green' and gating to push
> package changes to prod devices.

Which can be orchestrated.

> Thanks

Raymond Burkholder

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Reply via email to