Space is limited for the DevNet Women in Tech Workshop – Intro to Spark sessions, so register early! If you’re interested in chat bots, but aren’t sure how to start learning (and may be a little intimidated by the word “code”), then this introductory workshop is for you! Chat bots are the big buzzword of the year, and we want to show you how you can build your own in Spark. Yes, there might be a small amount of code to learn, but in this collaborative workshop DevNet experts are here for you. We will hold your hand, I was thinking figuratively so you can type, but if you need a real hand to hold we can do that too! In this workshop you will learn how to make Spark API requests and create a Spark chat bot. The purpose of creating a bot is to automate a frequent response. For example, you could ask the bot in a Spark room a question and the bot will provide an answer. It looks like magic when the bot responds, but we’ll go behind the curtains to see how the bot is created and how you can create your own. Here’s how to get started: Register for the Monday or Friday workshop (both have the same content) Bring your laptop, power cord and your “I can do it!” attitude to the workshop DevNet Developer Evangelist, Tessa Mero will teach you how to make Spark API requests, and I will show you how to create a Spark chat bot. I hope you'll join me for this fun and productive workshop. You'll be amazed at what you can do. See you in Berlin! Adrienne Moherek @amoherek P.S. If you want to get a sneak peek at the content in the workshop, you can check out the Spark sections within the Cloud Collaboration Learning Track. ... View more

Say “hello” to my little friend... Since bots have been the popular buzzword this year, we want to make sure you’re not missing out on all the action. Collaboration tools are evolving and integrating fast. Whether you’re interested in building your own bot or integrating Spark with another app, here at Cisco we’ve got you covered. I’m happy to announce the Cisco Spark Apps Community of Interest.  This is where you can start your journey as a “DevNet Sparker”.  You can explore integrations in DevNet Creations, learn how to build an app in the Learning Labs, connect with peers in #spark4dev room, and promote your own app in the Spark Depot. From the Spark Depot, your Spark app will get global visibility and hopefully the success it deserves. Ready to get started? We have a ton of resources to help you build your first bot or integration. Check out the Spark Depot to start integrating Spark with popular tools like Box, GitHub, Salesforce and more. Learn how to use the Spark APIs to create your own bot and/or integration in the Cloud Collaboration Learning Track Jump straight into the code with SDKs and sample code in Awesome Cisco Spark We hope you have fun creating some awesome apps. If you’re an engineer or developer wishing you could do something a little more creative, now is your time. Turn off a lightbulb from a Spark room, get notifications from a Jira update, find an available meeting room in your building. The sky’s the limit! I f you already have a bot that can be inspiring for others, go to DevNet Creations to share the code with the community. So glad to have you in the community Thanks, Adrienne Moherek @amoherek P.S. Don’t forget to check out the Spark Apps Community ... View more

I had the pleasure of supporting and attending the PNWPHP Conference in Seattle. I think the most asked question is what is Cisco doing at a developer conference? Surprise! We have APIs! The developers were super receptive to our Spark and Tropo collaboration APIs and eager to learn more, and even more excited to learn how easy it was to get started. What I enjoyed most about the conference was the close-knit feel. We all ate together and drank together. In addition to the technical talks, there were talks about mental health and wellness, developer evangelism and developer communities. I learned about OSMI, a non-profit organization bringing mental health awareness to the developer community. The founder Ed Finkler gave a wonderful emotional talk on Friday night that ended with a standing ovation. I encourage you to check out their website. They have great resources for employees and employers. Here’s my top 5 list: PHP elephants - Everyone was trading and collecting all different colors Diverse talks – Technical and non-technical talks. Check out OSMI Food and drinks - Vegan, vegetarian and gluten-free food options Great location – Walking distance to hotels, restaurants, and Space Needle Tessa – Great job coordinating the entire conference! The kudos just keep on flowing: ... View more

We are excited to announce a winner for Meraki gear on Wednesday July 13 during Susie Wee's Keynote in the DevNet Theater at 12. One winner will receive an MR32 (a badass indoor access point) and MX65 (cloud managed networking and security appliance) And MS220-8P (cloud managed 8 port PoE switch)! Details: Enter a question in the Meraki community; it's that easy. A judge will pick the best question, and announce the winner on stage at Susie Wee's Keynote: Unleash Your Geek with DevNet – Everyone is a Developer in Today’s Innovation-Driven Economy Important: Winner must be present to win We have Meraki experts standing by to answer any and every question. We are looking for insightful questions. Let's put the industry experts to the test! Asking a question in the Meraki community is easy: 1. Register for Cisco DevNet 2. Go to the Meraki Community and login with your Cisco Id 3. Click on "Start a Discussion" link in the blue box 4. Provide a title and description of your question Happy posting! - Adrienne Moherek ... View more

Cisco Application Centric Infrastructure Design Guidehttp://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-731960.html http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-731960.html Complete list of resources ... View more

Valuable video resources that cover technical information about ACI: TechWiseTV: Fundamentals of ACI TechWiseTV: Inside the Application Centric Infrastructurehttp://www.cisco.com/c/en/us/training-events/events-webinars/webinars/techwise-tv/inside-aci.html TechWiseTV: Inside Cisco’s ACI Controller: The APIC Containers Are Hot, but How Do They Network? Moderated by Eric Hanselman, 451 Research ... View more

Created by Adam Raffe Using the APIC GUI to configure the environment is fine for small environments or for becoming familiar with ACI, but what if you need to configure 100 tenants, each with 50 EPGs, tens of private networks and bridge domains, multiple contracts to allow traffic and a L3 Outside or two thrown in? Configuring all of that through the GUI is clearly going to be very time consuming and probably quite error prone, so we need to find a better way of doing things. ACI has a wide variety of programmability options that can be used to automate the provisioning of the fabric and its policies. One particularly strong aspect of ACI programmability is how easy it is for network engineers to start interacting with the fabric in a programmatic manner. Speaking from personal experience, it’s incredibly easy for someone with a ‘traditional’ network engineering background with limited development experience to start using the programmability features of ACI. With that said, let’s take a look at some of the options we have around ACI programmability: Native REST API using XML or JSON ACI Python SDK (“Cobra”) ACI Toolkit Let’s take a look at the native REST API option first. Native REST API The first option – and arguably the one most people look at first – is to interact with the APIC API using raw XML or JSON. Using raw XML / JSON has the advantage of not requiring the user to have any real programming knowledge (for example, Python) and interacting with the REST API natively can be done through a variety of tools (e.g. any tool capable of posting data to a URL such as cURL, Postman plugin for Chrome, etc). So how do we get started with this? Before you start, it’s worth bearing in mind that to use the REST API effectively, it’s useful to have some understanding of how the object model works. For example, if we want to create a tenant, private network, bridge domain and EPG using the API, we need to have a bit of knowledge about how these objects relate to each other. Fortunately, the APIC provides some tools to help us understand this – one of which is the object store browser (Visore). To get to Visore, browse to <APIC-IP-address>/visore.html and log in - alternatively, select Object Store Browser from the welcome menu in the APIC GUI. Once in, you’ll be able to query for classes or objects using the search box at the top of the screen. In this example, I’m going to search for all instances of class fvTenant: In the above screenshot, my query has returned 32 objects of class fvTenant (I have 32 tenants on my fabric), two of which I have shown here. From here, you can see the distinguished name of each tenant object (e.g. uni/tn-LAN01). Now, the really useful part of this is that clicking the right arrow (>) next to the distinguished name will take you to another screen showing all of the child objects of the tenant object in question: In the above screenshot, you can see two of the child objects for my tenant (named “adraffe-test”) – specifically, we see an application profile (class fvAp, named “Test-App-1) and a bridge domain (class fvBD, named “Adam-Test-BD”). Scrolling further down reveals additional objects such as private networks, contracts and filters. Clicking the right arrow next to the DN takes you further down the tree – for example, drilling further into the “fvAp” object here would take me to the EPG objects contained within. Now that we have some knowledge of the object model, we can start with some basic interaction with the REST API. The first thing I need to do is authenticate, which I can do by posting to the URL in the screen shot below and sending the XML shown: Now that I’ve authenticated, I can start creating objects through the API. I’ll start by creating a new tenant named ‘Finance’: That’s it – sending that simple piece of XML to the APIC created a new tenant. Now let’s create a private network, bridge domain, application profile and EPG inside my new tenant. I post to the same URL as in the last example (the “uni” in the URL is used to represent “policy universe”), but this time I send the following: Let’s take a closer look at what this XML does. Firstly, I need to include the tenant object I want to modify (Finance). I then create a new private network / VRF (fvCtx) named Finance-Net. Next, I create a bridge domain (fvBD) named Finance-BD, with a subnet address (fvSubnet) of 10.1.1.1/24. I also create a relationship between my new bridge domain and the private network I created earlier (using fvRsCtx). Next up, I create an application profile (fvAp) called Finance-AP1 and add a new EPG (fvAEPg) to it named Finance-EPG. Finally, I create a relationship from my new EPG to the BD I created earlier (using fvRsBd). This is extremely easy to get the hang of – you can use the API inspector and “Save As” tools which I referred to in my earlier post (as well as Visore) to help you to get familiar with the object model and build your own scripts. ACI Python SDK (Cobra) If you are familiar with Python, Cisco have a Python SDK (also known as “Cobra”) available. This SDK allows you to build a Python program to make API calls to the APIC without having to post raw XML or JSON as in the last example. You still need a working knowledge of the object model, which again the tools mentioned above can help with. As a comparison, let’s take a look at the equivalent Python code which would create the same tenant, private network, bridge domain and EPG we created earlier (note that there is more to this script not shown here, such as importing the relevant modules, logging into the APIC, etc): Anyone not familiar with Python may at this point be wondering if they should steer clear of the Python SDK – however, fear not: there is an extremely cool tool which will take the XML or JSON which you provide and automatically generate Python code for you. This tool is called arya (APIC REST Python Adapter) and is available here: https://github.com/datacenter/arya You can see this tool in action by simply downloading some XML / JSON from the APIC using the “Save As” feature and then feeding the file into the arya tool. The tool will generate the equivalent Python code for the XML or JSON you provided. Pretty cool, right? ACI Toolkit The final option I’ll look at here is the ACI Toolkit. One of the considerations when using either the native REST API or the Cobra SDK is that you do need to have some familiarity with the ACI object model. That’s not necessarily a huge mountain to climb, but some people may be looking for a quicker and simpler way of accessing the programmability features available with ACI. Step forward, ACI Toolkit. The ACI Toolkit is essentially a set of Python libraries which takes the ACI object model and abstracts it into a greatly simplified version. Right now, the ACI Toolkit doesn’t provide full feature coverage in the same way that the native API or Cobra SDK does, but if you are looking for a simple way to create the most commonly used objects (EPGs, BDs, private networks and so on) then it’s worth taking a look at what the Toolkit can offer. Here is an example of how the ACI Toolkit can be used to create some common objects within ACI: One other nice bonus of the ACI Toolkit is that a number of applications are thrown in, such as the Snapback app (used for config rollback within ACI), End Point Tracker (used to keep track of and display end point information within the fabric), various visualisation tools and more. You can get more info on the ACI Toolkit, including instructions to install here. To sum up, hopefully it’s clear from this post that programmability in ACI is not limited to developers – anyone with a background in traditional networking should be able to get up to speed reasonably quickly and be able to start taking advantage of the benefits associated with programmability. Thanks for reading. ... View more

Created by Jason Gmitter ACI programmability is rightfully getting a lot of attention lately due to its robust GUI and a RESTful API that supports both JSON and XML. ACI 's RESTful API will drastically help reduce the time it takes to deploy new network policy, update existing policy and deprovision policy for a new or existing application. Therefore, as a network engineer with 15 years in the industry and mostly only touching a CLI, I started to ask whether I should learn the GUI or learn how to leverage the RESTful API to reduce provisioning and deprovisioning times. I decided to invest my time in learning how best to take advantage of this rich API. However, I did recognize the ACI GUI is great for creating best practice configurations and verifying and testing them; but, leverage the API to automate the configurations best practices I created from the GUI for any new add, moves, changes or deletions. I started researching the tools Cisco currently makes available to help a CLI jockey learn how to use this API. Onhttps://github.com/datacenter, I came across Arya, CobraSDK and ACIToolKit as popular tools to program ACI. Which one should I learn first? Arya (https://github.com/datacenter/ACI/tree/master/arya) is a code generator. It essentially allows me to save APIC objects in XML or JSON format that I created in the GUI and convert them into ACI Python SDK code, where I can automate and deploy configurations in seconds. For example, I can take JSON or XML from APIC Visor, the API Inspector or a REST query, and generate Python source code to build a full configuration in seconds. There are some caveats: Arya doesn't validate configurations or perform advanced lookup logic, but it's a great way to create code from JSON or XML objects or classes that already exist. I view it as a great tool to help with creating great code with the Cobra SDK. But I wasn't ready to create code yet. Next, I looked at the Cobra ACI Python SDK (https://github.com/datacenter/cobra). Cobra has an all-inclusive ACI object model implemented that can essentially do everything to configure an ACI fabric. It not only has a Python library that provides native bindings for all the REST functions but also a complete copy of the object model, which means data integrity can be ensured. This is important as it validates the configuration before executing it on APIC. The Cobra SDK provides methods for performing lookups or queries and object creation, modification and deletion that match the REST methods used by the GUI. What's cool is that I can take policy built in the GUI and use it as a programming template to build new code for super fast deployments for other tenants and their applications. Here's a link to the Cobra API documentation (http://cobra.readthedocs.org/en/latest/). Although I felt I wasn't quite ready for Cobra, I knew I would want to come back and learn how to use this SDK. If new to Python here is a great place to start: http://www.pythonlearn.com/ https://docs.python.org/2/tutorial/index.html http://www.learnpython.org/ https://developers.google.com/edu/python/ Ultimately, I decided to learn the ACIToolkit first https://github.com/datacenter/acitoolkit. The ACIToolkit is very use-case oriented; for example, it knows how to build an EPG, but doesn't know how to manipulate all of the underlying objects and class inheritances. The ACIToolkit also provides an NXOS like CLI for ACI; therefore, I can leverage some of my CLI skills. Here is an example of some of the CLI available to configure ACI: https://github.com/datacenter/acitoolkit/blob/master/applications/cli/clicommands.txt Take a look at a sample ACIToolkit script for building out a simple tenant and the application network profile to support a new application deployment at https://github.com/datacenter/acitoolkit/blob/master/samples/aci_demo_contract.py. I don't need to ssh or telnet to a number of switches to build this configuration, but instead I leveraged a single API where APIC distributes the policy to the fabric. You can imagine you can easily further customize this script to deploy for other applications. If you want to evolve past the CLI samples and dive into Python, take a look at an example that leverages a simple Python script to create a tenant with a single EPG and assign it statically to 2 interfaces: http://goo.gl/cLTYlR You can find a list of other ACIToolkit Python applications you can start to use athttps://github.com/datacenter/acitoolkit/tree/master/applications. One of my favorites is the end point tracker. It allows me to search for a mac address or IP address anywhere within the fabric. I can sort by Tenant, Application Network Profile, or by EPG. It's extremely flexible to have a single interface to configure, monitor, audit and troubleshoot the fabric. Lastly, you can find additional examples that allow you to build out the fabric or query information from the fabric leveraging ACITookit python scripts at https://github.com/datacenter/acitoolkit/tree/master/samples. The ACIToolkit is a great way to start to evolve from what I know with CLI, move onto python scripts, and get me ready to dive into learning the ACI Python SDK next (Cobra). In summary, I chose to start with ACIToolkit because I wanted something easy to learn. Start here and go through the documentation: http://acitoolkit.readthedocs.org/en/latest/and let me know what you think. You can install the ACIToolkit as a VM, Docker image or just git clone and run natively on your PC or MAC. https://cisco.app.box.com/s/j0jlkl3b1m7yj6oqm3e5yazesfkiicsh https://registry.hub.docker.com/u/dockercisco/acitoolkit/ https://registry.hub.docker.com/u/dockercisco/aci/ To get you started, I provided a short video to show you where to get started and a few sample demonstrations. Enjoy! For clearer video: ... View more