TechWiseTV Workshop: Open NX-OS and Devops with Puppet Labs

Editor's Notes

• #6: This slide should state the level & Learning Objective the audience should be at: Today we are here to understand the Messaging, Positioning and gain the ability to Differentiate … Or Today we are here to Design, Deploy, Competitively position within product X, (or) Solution X …
• #11: Guestshell easier to use, no need to build a distro, yum install from centos repository into your guestshell.. For most part just works, running with less access than the host. We’re not in same linux network namespace as the host, so we can do monitor stuff with netdevices ports, run ethtool monitor stats, parameters, etc, but we cannot change stuff from within guestshell. We turned off ability to change interface parameters, mtu, addresses, etc..anything that changing networking within guestshell, no network admin capabilities from a linux networking perspective..do host conf t, eth4/1 shut..system call to nxos essentially. Run bash or run guestshell… From guestshell, can’t shut down interfaces… Lot of stuff you can’t do in Linux that you can do in NXOS..WNL Chef/Puppet native on switch or CentOS distro within guestshell 9504-B# guestshell resize ? cpu Resize the system CPU share allocated to guest shell memory Resize the system memory allocated to guest shell rootfs Resize the guest shell root filesystem to a larger value Apps within guestshell run in default vrf, if for example you wanted an application ro run in a different vrf, you could run linux chvrf within the guestshell to switch to it to run the application.
• #16: User installs & configures the agents on Cisco switches. Our goal is to automate this step using ISV specific tool  (Chef Provisioner) or home grown tool (for Puppet). Download agent RPM  from ISV site Install agent RPM on switch Configure agent to talk to the proper server/master User installs the Cisco Cookbook/Puppet Module (along with Cisco utility GEMs) on the Server/Master User creates a recipe or defines a manifest using the resources available in the cookbook/module.  If agent is configured to run periodically, it will obtain download the cookbook/catalogue and attempt to converge the network element to the desired state.  
• #18: Sales Presentation Deck – 4Q FY2016 –v7
• #19: Puppet Labs exists to reduce the timeline: from the moment you have new technology, to the moment it’s in the hands of your users delivering value. That new technology comes in a few different flavors. First, new applications. Maybe you’re deploying a new application that your team built, tested and is ready to deliver to the business. It might be a new application you bought from a vendor and you’re preparing to roll out to users. Second, new infrastructure. For example, maybe you’re deploying an OpenStack environment or spinning up a new greenfield project in AWS. Third, updates to existing services. Maybe your adding a new set of capabilities to an application the business already relies on. And lastly, configuration updates. Maybe there have been key configuration settings that have drifted from the state they should be in and you need to bring those systems back into compliance. In any case, we help reduce the timeline of getting that update out to your users, and help you do so with the reliability, predictability and repeatability you demand. What’s interesting though, is that each customer has different timelines at play. When I talk to Wal-Mart, out of the 40+k nodes they manage with Puppet, about 11k of them are on SLES 11, and they are trying to move another 6k from SLES 10 to SLES 11. Puppet helps them reliably reduce that timeline. At a very different looking user like Spotify, the notion of SLES is nearly laughable. We talk to them about how they are managing a sophisticated containerized environment. But as different as the technologies are, the common thread is that both organizations are cycling out older technology and cycling in newer tech and updates – and Puppet helps them do that.
• #20: As we work with organizations to accelerate the delivery of value to the business, we see a common set of challenges and critical initiatives organizations use Puppet Enterprise to help address. [read through key challenges and initiatives that you’ve discovered they are trying to address]. Does this list make sense? Any that shouldn’t be on the list for you? Any that stick out? Any that aren’t on it but should be? [Use this line of questioning to tease out team dynamics and concerns that you should be aware of as you pursue the deal.]
• #21: Our software helps you automate the configuration and ongoing management of your machines and the software running on them, so you spend less time fighting fires and more time deploying great software. We help you make rapid, repeatable changes and automatically enforce the consistency of systems and devices–across physical and virtual machines, on prem or in the cloud.
• #22: Key points. [The minimum points that a rep/SE should make. However, this is a good time to dig into details or have the SE lead a whiteboard discussion about our approach if you know this is an area of interest]. Our declarative, model-driven approach where you focus on defining the desired state of infrastructure, services and apps rather than the programmatic steps it takes to get there. Once you’ve modeled your infrastructure/apps, we make it possible to test your code to see what happens when you deploy that app update, etc. We also automate the deployment of that desired state to the infrastructure, and continually enforce that your infrastructure matches your desired state. When it doesn’t we let you know so you can remediate ASAP. This approach is model once, use everywhere. Once you model your infrastructure and your applications, you can deploy those changes to dev, to test, to staging, to production. It’s the same set of Puppet code that defines your desired state and we make that state so across your deployment tiers – there is no need to rewrite a new set of runbooks to programatically account for all the differences across environments. And all along the way, you get reports, so whether you want full traceability and insight through your environment or you need to meet audit requirements, you have the data you need about the state of your environments at your fingertips.
• #23: Key points. [The minimum points that a rep/SE should make. However, this is a good time to dig into details or have the SE lead a whiteboard discussion about our approach if you know this is an area of interest]. Provisioning is too often a slow process filled with manual steps. You should automate more than just the configuration management of your infrastructure or the orchestration of your apps, and extend automation to go across the entire lifecycle: from initial provisioning of infrastructure through decommissioning. Over the last few releases we added new provisioning capabilities making it easy to provision Bare metal and the OSs and hypervisors on those servers Virtualized environments like spinning up VMs with vSphere Public cloud infrastructure in AWS and Azure And Docker, both the Docker engine as well as Docker containers.
• #24: The best place to start is by managing your infrastructure as code. Our take is that infrastructure as code is a prerequisite for any DevOps or DevOps-like practice. When you treat your infrastructure as code it’s easy to share that code, collaborate around it, put it in a version control system, do peer reviews (rather than the big CAB meetings), unit testing, automate your deployments and more. After that, automating your configuration management and version control give you the biggest bang for your buck, meaning that you can make substantial gains toward the speed and reliability benefits we talked about earlier. Since managing your infrastructure as code is such a critical piece of a DevOps practice, let’s spend some time digging into what you should consider as you manage your infrastructure as code.
• #30: CI TOOLS: Jenkins, CircleCI, TravisCI CM TOOLS: Chef/Puppet/Ansible/SALTSTACK – we have a minion in our repo CL TEST SIMULATION: Beaker, v9k, VIRL, Kitchen CI, Docker, Vagrant, VMWARE, etc CD Tools: Github, Bitbucket Platforms: Cloud, Openstack RH Orchectrator, etc..
• #31: Vagrant Free runs on your laptop
• #32: Devops and Tooling Process Flow for Customer who has enabled devops processes and tools through out their infrastructure First some terms: Github – code repository GitLab is a web-based Git repository manager with wiki and issue tracking features. GitLab offers hosted accounts similar to GitHub, but also allows its software to be used on third-party servers. It is available as an Omnibus package. Bitbucket is the Git solution for professional teams Continuous Integration Tools Jenkins monitors the code repository for changes/notifications or updates, which trigger a build when they are detected. It calls an integration testing like beaker once build completes like puppet beaker to kick off a test run on the v9k staging fabric
• #37: Sequencing, this also effects your productivity and level of complexity you need to build into your automation design as you need to follow specific sequences of commands to execute something on the switch, as CLI needs commands in a specific order or will return an error. Same issue when you need to update something, need to no the specific previous command and redo with new values, very restrictive approach String Manipulation: With an industry standard based REST API’s if automation and network teams are separate teams, automation teams will understand REST API’s and manipulating REST API’s,
• #39: Maintainable from customers perspective as the object definition will not change/ Ops team that does potentially automation within access URL and an object, automation teams may not have networking expertise, but understand automation and programming constructs, makes it easier to teams to co-operate to automate. The automation teams understand industry standard restful based API’s, and will understand how to create, update or delete an object or its attributes using REST. REST is industry standard for APIs..
• #42: HOW DO WE FURTHER ENABLE YOU TO MOVE TO DEVOPS WITH TOOLING INTEGRATION WHAT PIECES ARE MISSING TO ENABLE YOU TO TRANSITION TO THIS MODEL?