some observations below:
> On 9 Aug 2017, at 21:52, Kasper Adel <karim.a...@gmail.com> 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
> 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
> 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.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.