Puppet for Junos

Hi Jeremy,

First of all - great work on the Puppet agent implementation - it's been something I've been meaning to try out for the last few months, and now that you've got it incorporated with Junos my reasons not to try it (I'm a comms guy) have evaporated!

After a day of hacking through the pitfalls of duplicate package management and invalid SSL certs, I now have a shiny new puppet-controlled EX deployment (The Junos side of the install was pretty smooth by comparison 😉 )

One of the things that struck me after setting this up was that the manifest commands that are available are all things that are very device specific like VLAN assignment and port configuration as opposed to things that better suit a template like DNS, NTP, authentication etc.

I wonder though what yours/Juniper's thoughts are on how much of the Junos vocabulary/syntax you'll be looking to expose in future?

Some sort of code generator that takes in each Junos release schema and spits out the associated puppet module? (Hey a guy can dream!)

After a day of hacking around, I still prefer Junos Space templating over Puppet due to it's easy mental model and GUI, but I think this has real promise for the DevOps guys who already use Puppet for their infrastructure.

Keep it coming!

Hi Ben,

Thank you for taking the initiative to explore Puppet for Junos!  It's great to see the "networking guys" taking interest in this technology. 

As you may have read in the FAQ, Puppet for Junos was developed to bridge the "automation gap" between the networking teams that wanted to allow IT/DevOps to make basic/common changes with switching; like VLANs/ports/LAGs/etc.  IT/DevOps were already using Puppet to manage their IT infrastructure, and Puppet enables them to coordinate their changes that would have instead required some kind of "request ticket" process with the networking teams.  So that's the background; hope that makes sense.

When we developed the Puppet "netdev" module, we had a few driving principles in mind.  One was: create a flexible framework so that people (DevOps/"Puppet programmers") could add whatever functionality they wanted without having to wait for Juniper.   So "netdev" is hosted on Github, and people can take a fork, make changes, and choose whether or not they'd like to upstream it back. 

It's also great to hear you're using Junos Space for your templating purposes.  Again the driver for Puppet for Junos was to bridge the automation gap; enable IT/DevOps to use their tools to do what they need and at the same time the Networking teams can use the tools they like and need.   The intent was to enable "IT automation" and have complimentary tools and options.

Thank you again for checking it out, and we look forward to your feedback/suggestions/ideas!

Cheers,

-- Jeremy