July 9, 2014 1 Comment
Avatar
Data Center

The Napkin Dialogues: Nexus Programmability, Part II

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.

[*Again, still not a real person]

In the last post we had gotten as far as describing different ways to access the CLI on a Nexus switch, including an on-box Python interpreter (which I hadn’t known about) and the usefulness of NetConf:

Bringing out the napkin
Bringing out the napkin

As we returned from our beer-imposed bio-breaks, we sat back down and started getting to the point that I really wanted to know about.

onePK

“Okay, Jim,” I said, as another round came to our table. “You’ve taught me some stuff I didn’t know. I was having a really hard time understanding what the big deal was about programmability and scriptability. I thought that all programmability really meant was that we were opening up a SSH session to a switch and running some sort of script to screen-scrape CLI commands, I guess.”

Jim nodded. “Yes, as you can see it’s a bit more involved than that.”

“Yeah,” I admitted. “You don’t know what you don’t know, right? So what’s all this Puppet and Chef stuff that I keep hearing about?”

Jim looked at me thoughtfully as he took a sip of his beer. “Before we get to that,” he said, “it will probably be better if we start talking about onePK.”

“Okay,” I said, trying to be patient. “I’m still a sponge.”

“You remember that we were trying to figure out all the ways to get the switch to do something, like shut or no-shut a port, right?” he asked.

“Sure,” I said. “So far we’ve looked at a couple of ways of getting the CLI to do what we want it to do.”

“Yes,” Jim said. “As it turns out, there are other ways to talk to NX-OS besides the CLI. For example, there is the Cisco onePK”

“Ah, yes,” I said. “I’ve heard about that. What is it?”

“That’s a good question,” he said. “Cisco’s onePK is a platform kit – that’s what the PK stands for – that directly ties into the switch’s capabilities.

onePK APIs talk directly to the OS
onePK APIs talk directly to the OS

“At the bare essence, onePK is a software development kit – or SDK – for Cisco platforms,” Jim explained. “It’s another way to interact with the switch or router at the OS level. That SDK is, in turn, a set of application programming interfaces, or APIs.”

He stopped and thought for a moment. “You probably already know this,” he said cautiously, obviously not wanting to offend me, “but APIs are like the C-3PO of device communication.”

“What do you mean?” I asked.

“Well, do you remember how C-3PO was fluent in over 6 million forms of communication?”

I nodded.

“It’s like that. You talk to him in the language that you understand because he also understands it, and he converts it into another form,” he said. “Sometimes he takes a command and tells another device to do something.”

“Oh! Oh!” I said, getting excited. “Like the trash compactor scene, where Luke tells 3PO to shut down all the garbage mashers on the detention level, and 3PO tells R2D2 to interface with the commands of the Death Star.”

 

He looked at me funny. “You know that movie waaaay too well,” he said.

I pouted, fiddling with the beer glass. “Well, it’s a good movie.”

“Anyway,” he said, drawing out the word. “Yes. Exactly like that. Although I suppose in that scene it was really R2D2 that was the analogy for the API, but you’ve got the idea. In any case, onePK allows you to create applications that can give you some flexibility in automating, monitoring, troubleshooting, etc., the network. It gives people direct access into the switch capabilities and allows them to speak their favorite native language, like Java, Python, or C.”

“Can you give me an example?” I asked.

“Sure,” he said. “Let’s just take the example of monitoring a switch. Or, even better, you want to make sure that the actual cabling you’ve designed for your topology is exactly what is configured. I know you’ve done this before, where you think you’ve wired everything up properly but in reality it’s not.

“So, you create a wiring verification script. It polls the switches for the actual wiring topology and compares it to intended diagram,” he continued. “In essence, you set up the baseline, and then you just use onePK to watch for changes, at which point onePK sends the event to an external application. So, in practice, if something’s wrong, you can have it set up to send you a text of exactly where the problem is, and what the solution should be.”

I nodded. “I can see how that would be particularly useful in situations where you have a facilities technician who’s in charge, or perhaps in a co-location facility,” I said, stroking my chin. “Yeah, that would be really helpful.”

“Precisely,” he confirmed. “In fact, at the moment onePK really shines in these kind of event management – EEM – things. If you want the switch to tell an application that’s off the box that something is happening, onePK is the way to do that. Otherwise you have to attach to the switch and check to see what’s happening on-box.”

“So, if I understand correctly,” I said, trying to summarize, “If I want to use some of these kinds of features using onePK, I’m going to have to learn how to program in C, or Java, or Python.”

He shook his head. “Not necessarily. Sure, if you’re a network administrator who has some small scale automation that you want to run, like the texting application I just mentioned, sure. Or perhaps you want to do some data-plane or event-driven extensions in your network. But if you want to do some ongoing work, you’ll generally work with plug-ins or agents that communicate with the onePK APIs.”

“So this is the NetOps- and DevOps-level stuff, right?”

He nodded. “We can go over a bit more about onePK later if you like and talk about the mechanics in greater detail at another time, but for now I think you have a good enough starting point. Now is the time that we can start combining our tools.

“We talked about Python before, and how it was useful both on and off the switch itself. When you combine it with onePK, though, you can do some very interesting things. When you get a chance, you should take a look to see what David Gee has written about how to use Python with onePK. It’s an excellent guide for some beginner work with the tools.

Puppet and Chef

“Speaking of onePK,” Jim segued. “it’s a great lead-in to the conversation about Puppet and Chef.”

“Why’s that?”

“Because onePK is the piece that Puppet and Chef use in order to interact with the switch,” Jim said.

Puppet

“Puppet is, essentially, automation software. It’s used predominantly on servers, because it helps system administrators manage and provision them. It makes sense that if you can use these tools to manage servers, you should also be able to manage network equipment as well.”

“Okay, I get that, but can you be a little more specific?” I asked.

“Sure, but it’s pretty much the same thing we’ve been talking about at a higher level,” he said. “Let’s say you have a lot of servers that need to be configured in a similar fashion. Puppet lets you do that, and also lets you have control over all those machines.”

“And it’s Open Source?”

“Yes, but it’s managed at the enterprise level by a company called PuppetLabs. It’s free up to 10 nodes for Puppet Master Enterprise, while in the Open Source version the number of nodes is unlimited.”

“How does it work?” I asked. “With Nexus, I mean.”

“Generally speaking,” Jim said, starting to draw on the napkin once more. “It works on a master-agent basis. There is a master Puppet controller that talks to an agent which is located on the end device. On a Nexus switch, Puppet talks to the onePK API interface for NX-OS.”

 

The Puppet agent sits on top of onePK
The Puppet agent sits on top of onePK

 

I was starting to understand how the pieces were falling into place. “I see,” I said. “So the agent talks to the master Puppet controller outside of the switch, and talks to onePK on the switch in order to get things done.”

“Right,” he confirmed. “Those things that you are talking about are plug-ins for onePK, called manifests.  Effectively, they’re the files that describe the machine configurations.

Chef

“What about Chef?” I asked. “Isn’t Puppet and Chef the same thing? I hear those two terms used together a lot.”

Jim shook his head. “No, Chef is the direct competitor to Puppet; they do the same work, written in the same language – Ruby – just developed by different companies. It’s managed by a company called Opscode. Both Puppet and Chef allow you to manage devices across the data center (both servers and switches), and both provide certain automation functions.”

“Which one is better?” I asked, feeling cheeky.

Jim smiled. “Nice try,” he said, wagging a finger. “As well you know, the one that’s better is the one that you want to use. Usually the server administrators make the call about which is the best for their needs, then try to extend those tools to the network devices.”

I grunted. He wasn’t going to allow himself to be caught out. “But for our purposes,” he said, returning to the subject at hand, “they sit in the same place on the switch, which is on top of the onePK component.”

The Chef agent also connects to the onePK API
The Chef agent also connects to the onePK API

 

“Because of this, the Chef plug-ins, called recipes – get it? Chef? Recipes? Never mind – also have a master Chef that controls the agents on the switches by connecting into onePK.”

“So using these tools allow you to configure and control at scale,” I said.

“Yes,” he replied. “More importantly, it allows you to use the same toolset to manage the network that server administrators use, which helps them maintain consistency across their management needs.”

Something occurred to me. “You said that Puppet and Chef  are written in Ruby,” I said.

“Yep, that’s correct.”

“Does that mean that we run Ruby on the Nexus switches as well as Python?” I asked.

He shook his head. “No,” he said. “In reality the only way to use Ruby to connect or control a Nexus switch is through Puppet or Chef by using the agents written on top of onePK.”

“I see,” I said. Then, following up, I asked, “Can I write a plug-in for onePK in Ruby?”

“I’m afraid not,” he said. “At the moment the support for languages on onePK comes with the related SDK only for Java, Python and C.”

“Okay,” I said. “I just was curious.”

Moving On

I was happy that I felt like I was starting to get a handle on all this stuff, but at the same time I knew I had a long, long way to go. I must have allowed my anxiety to show on my face, because Jim paused and took stock of my reaction.

“Don’t worry,” he said. “Slow and steady wins this race. It’s not so much about knowing what the next greatest tool is, but rather how it relates to your equipment and environment, not to mention your business needs. People spend day-in and day-out becoming very good at any one of these things, so you’re not expected to become a master of everything here.”

“I know,” I said. “I’m still trying to cope with knowing what I don’t know. I mean, I’ve gone through some of the links you’ve given me and it still seems like there’s a big jump from what you’ve been talking about and where I need to be in order to feel like I ‘get it.’”

“Patience, child,” he said, grinning as he chided me. “This is all about learning a new alphabet, which is always slow and frustrating at times when being introduced to a new language.”

“You’re right about it being frustrating from time to time.”

His grin broadened. “Frustration is your brain’s way of telling you that you’re learning something.”

I grunted.

“Look,” he said, pulling out some new napkins. “Go get us another round, and we’ll finish this up when you get back with some talk about the built-in web server, NXAPI, and the interesting things you can do with JSON and XML.”

Additional References

Cisco ONE/onePK

Blogs

 

Puppet

 

Chef

Podcasts:

 

Special Thanks and Acknowledgements:

None of these blogs could have been written without the help and assistance of “Jim,” who is made up of a large number of people who deserve my profound thanks and gratitude for their patience in explaining things to me: Chhavi Nijhawan, Fabrizio Maccioni, Drew Pletcher, Shelly Cadora, and Bhanu Vemula