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. https://ripe72.ripe.net/presentations/58-RIPE72-Network-Automation-with-Salt-and-NAPALM-Mircea-Ulinic-CloudFlare.pdf 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 needed. > > 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 https://blog.raymond.burkholder.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
