- Your love of OpenStack is not enough.
You’ve had your “Aha moment.” You get the OpenStack value proposition. You’ve listened to other customers talk about their success with it. You can see the problems it’s going to solve for your organization. You are all in.
But it’s not enough. Just know that. Even if you’re the decider-in-chief, and you can make the call to start an OpenStack initiative at your company tomorrow, you’ve got another, bigger job on your hands, and that’s changing your company culture.
So say the panelists that were speaking at a Cisco-sponsored session yesterday about their experiences with OpenStack. They agreed unanimously that the technology is not the challenge when deploying an OpenStack-based private cloud. It’s changing the company culture. Giving developers more freedom and trusting them to do great things (which a proper cloud will in fact enable them to do), vs. controlling them tightly in a traditional IT environment. It’s embracing the “Fail fast, fail small, fail often,” model that allows for quick learning and innovation.
One panelist said, “The technology is there. It works. It’s easy to use. But changing how people use it is the hard part.” Another pointed out that it’s even harder if you’re in an established (non-startup) company with yearly CapEx cycles and capacity planning. “It’s difficult to get groups to buy in on an OpEx model and move away from their established processes,” he said, with a look that suggested he’s been down that road. A third mentioned “dragging them kicking and screaming” as part of his strategy to get his company there.
Read More »
Tags: openstack summit, PTL, python
Cisco, in its quest to embrace programmability, has created what is called the ACI Toolkit, which is basically a combination of an NX-OS like CLI and some custom python scripts. Although this toolkit doesn’t allow you to do all configurations within ACI, it can be used to create and show the common configuration and administrative actions that may be used daily. It’s also great for someone who is just starting to migrate to a more programmatic way of doing things, as it’s easily understandable to folks used to common networking commands.
If you’re not familiar with ACI, check out this short video to get a brief understanding of some of the basic constructs used and for a deeper dive go to www.cisco.com/go/aci. These concepts will help you to understand some of the configuration options available with the ACI Toolkit.
The toolkit’s python libraries are all available on GitHub.com and it’s fairly simple to access. All you need to do is open a terminal window on your computer and enter the following command:
git clone https://github.com/datacenter/Simple-ACI-Toolkit
This command will download the necessary libraries to use the ACI Toolkit syntax. Then to run CLI commands from your APIC type:
python acitoolkitcli.py -l admin -p password -u https://APIC_IP
This will connect you to your APIC so you may run commands that will help you build your application network profiles as shown in the three tier application in the picture above. We can do things such as switching tenants, creating contexts, creating bridge domains, and creating end point groups (EPGs).
Here are some examples of the common commands we might use to create these logical objects.
Switch to a tenant configuration mode:
- fabric# switchto tenant <tenant-name>
- fabric-tenant# switchback
Create a Context and don’t enforce contracts on it:
- fabric-tenant(config)# [no] context <context-name>
- fabric-tenant(config-ctx)# [no] allow-all
Create a bridge domain and assign it to a context:
- fabric-tenant(config)# [no] bridgedomain <bd-name>
- fabric-tenant(config-bd)# [no] context <context-name>
Create a subnet under the bridge domain:
- fabric-tenant(config-bd)# [no] ip address <ip-address>/<masklength> [name <subnet-name>]
As you can see from these examples the syntax will be very familiar to network engineers. We can also use the ACI Toolkit combined with the Python SDK to actually script these things. It makes scripting a little easier because we’re again using simpler syntax. Below is an example of configuring a tenant using Python in conjunction with the toolkit:
from acitoolkit import *
from credentials import *
tenant = Tenant (‘Customer1’)
context = Context (‘customer1-router’, tenant)
bd = BridgeDomain(‘BD1’, tenant)
app = AppProfile(‘web-and-ordering’, tenant)
vlan10 = EPG(‘VLAN10’, app )
vlan20 = EPG(‘VLAN20’, app )
Currently the ACI Toolkit may not be used to create service graphs, VMM Domains, SPAN, Atomic Counters, and or to see most telemetry and health score information. However, the toolkit still gives us a lot to work with and automate as far as basic configurations go. For more information please see the guide found here (http://datacenter.github.io/acitoolkit/).
Tags: ACI, Cisco, python, toolkit
In this week’s episode of Engineers Unplugged, we welcome for the first time (and not the last) guest host Janel Kratky (follow her @jlkratky)! She’s hosting Jason Pfeifer and Glue Network’s Gregg Wyant as they discuss onePK and how to apply it to the real world. You don’t want to miss this one, it ends with a Glunicorn.
If you would like to become Internet Famous, and strut your unicorn talents, join us for our next filming session at VMworld 2014. Tweet me for details!
This is Engineers Unplugged, where technologists talk to each other the way they know best, with a whiteboard. The rules are simple:
- Episodes will publish weekly (or as close to it as we can manage)
- Subscribe to the podcast here: engineersunplugged.com
- Follow the #engineersunplugged conversation on Twitter
- Submit ideas for episodes or volunteer to appear by Tweeting to @CommsNinja
- Practice drawing unicorns
Join the behind the scenes by liking Engineers Unplugged on Facebook.
Tags: cloud, data center, developers, Glue Networks, onePK, python
When last we left our hero, he (that is, me, or I) was getting a crash course in Nexus programmability and trying to understand what all of this stuff meant. I had plied Jim* with beer in order to get him to explain to me – using the available napkins in the bar – what the technology was, what it meant, and why I should care. Read More »
Tags: Chef, nexus, onePK, programmability, Puppet, python, Ruby
I know that I take a different approach to learning new things than most people. At least, I know my approach is different than the way people present them. The good news is that when I get something, I really get it. However, when looking at the juggernaut that is “Software-Defined X,” or even “programmability,” I know that I’m still a long, long way away from feeling like I have a handle on it.
When I wrote the previous blog post on some of the key “Open” terms were in programmability, I was overjoyed to find out that there were a few people who also had difficulty getting a grip on this too.
In other words, I’m not alone!
There is still a bewildering amount of information that I still need to learn, however, and it seems to me that if I resonated with a few people about these high-level topics, there are probably a few more who are curious about what lies beneath as well. Fortunately I work for a company (and with a lot of people) who have been willing to help me. Read More »
Tags: CLI, netconf, nexus, programmability, python, SDN