Thanks for all those who joined SDNCentral’s latest DemoFriday with Cisco as it showcased how to manage and orchestrate Cisco Nexus Switches with Puppet. The presentation included a demo of how the Puppet architecture can enhance management and condense deployment times of Cisco Nexus Switches, bringing the benefits of DevOps to the network. If you joined us, you also saw zero touch installation of Puppet agent, automation of software packages, VLAN assignments, as well as network-wide policy distribution using Puppet.
After the demo, our presenters took some questions from our participants. Below, you can read Cisco’s Q&A and learn more about how to manage Cisco Nexus Switches with Puppet. You’ll also find the full presentation, teaser videos, and other resources here.
Will the Puppet resource types work across vendors or specific to Cisco?
Cisco: The resource types that I showed in the demo are Cisco resource types. But, we are working very closely with Puppet Labs to make sure that these resource types can be contributed to net-dev types. Puppet Labs is working with other vendors as well to make sure we all come up with something that every vendor can support. This will be the best outcome for our customers. In cases where the resources on the routers/switches are unique to Cisco, you will definitely see Cisco specific resource types. When Puppet Labs and others agree on resource types, Cisco will support those resource types along with any Cisco specific resource types as needed to deliver an end-to-end solution.
This seems to work great for resource types you have today. What options do I have if I need to provision something that is not defined yet?
Cisco: This is a very practical situation many customers will get into when they start on the Puppet journey. They will definitely get into a situation where the resource type is not defined yet (in net-dev or by Cisco) for what they are trying to provision. We have two choices here.
Easy choice – you can use the Cisco Config command type that I described in the presentation and the demo as well.
Second choice and maybe an elegant one, you can create a resource type and provider code yourself. You have all the tools and infrastructure that you need for this purpose. NX-API is open, we have plug-in sync capability on the agent. Create a new type and provider code, download into the agent and you will be done. You can probably share that with the community as well.
Are these foundational blocks in NXOS specific to Puppet? Can I use them to implement other DevOps tools like Ansible or SaltStack or my own tool/applications?
Cisco: No, none of the foundational blocks are specific to Puppet. LXC, Guest Shell, NX-API and POAP are published as NXOS features and can be used for any purpose. By all means, you can leverage these features and augment Puppet agent implementation or implement your favorite DevOps tool. We would love to see customers, partners, and the open source community take advantage of these features and create something useful and benefit the wider community.
NXOS already supports NETCONF and other interfaces like REST on some platforms. Will the roadmap and support for those change with introduction of Puppet?
Cisco: We will continue to evaluate and evolve our device programmability and interfaces to cater to our customer’s needs. Customers are segmented when it comes to management interface choices – some like REST, some like NETCONF, some like Chef, and the list goes on. We will cater to all these segments with the infrastructure which makes it easy to develop these interfaces. NETCONF interface will continue to be supported. REST is also gaining momentum and you will see continued support and proliferation of REST interface.
What is the roadmap for Puppet Agent on various Cisco platforms?
Cisco: In the near term, you will see Puppet Agent support on Nexus switch platforms. A version of the Puppet agent is in Controlled Availability. If you want to check out the Controlled Availability version, please submit a request through your account team. Puppet Agent will be generally available on our flagship Nexus 9K in early Q2 of CY 2015. Other Nexus platforms like Nexus 3K, Nexus 7K, Nexus 5K and Nexus 6K will follow soon. Please submit a request through your account team if you are looking for non-Nexus platform support.
Do we need a separate Linux container to run the Puppet or we can leverage the REST APIs directly?
Cisco: Running the Puppet Agent on different server and leveraging REST APIs to control the switch is a viable technical approach. This type of proxying comes with its own overhead of allocating and managing yet another server though. In our analysis, customers preferred the model that is being used on the compute nodes which has tighter integration of Puppet Agent into each node, hence the current model supports on-box Puppet agent.
Will a whitepaper with this capability be authored soon?
Cisco: A brief solution document is published on cisco.com. You can find it here. Additional collateral such as white papers and detailed solution guides are planned at the General Availability time frame which is early Q2 CY 2015.
Cisco: Our goal is to enable seamless integration of Data Center Switch automation into DevOps tools that are already managing compute nodes and other infrastructure in the IT stack. This will enable the IT administrators to use familiar tools to make their IT agile and fast without redesigning their infrastructure. The direction here is to consolidate deployment automation tools.
My biggest problem is in the access layer. Will there be a puppet agent in the 3560V2 IOS switches?
Cisco: Puppet Agent support on a Cisco Catalyst switches are not in the immediate roadmap, but there are certain technical approaches that can be used in the short term. Please reach out to me via your account team for a deeper conversation.