In this video Ed Balduf (@madskier5) introduces the new Puppet module for SolidFire. Ed walks through the framework of the integration and demonstrates how Puppet manifests can include configurations of SolidFire storage configurations, including our performance QoS settings.
Download the code at https://github.com/solidfire/solidfire-puppet
Join the conversation at http://developer.solidfire.com
Hello, this is Ed Balduf with SolidFire and today I'm going to take you through some examples and demos of how to use the SolidFire Puppet providers to manage accounts, volumes, and volume access groups on the SolidFire cluster.
Let's begin with the, as you can see I've got four windows here, the top two windows are logged into my Puppet server and the bottom two windows are logged into two different clients. We're going to show you how to do this in two different ways. Let's start by looking at our manifests that we're going to use. Basically we're going to use generic site.ppmanifest and I'll walk you through what we've got going on here.
The first stanza here is actually the second thing we're going to work on which is where we define the node to be the name of the SolidFire cluster. We're going to use the Puppet device constructs to take advantage of this. You can see I've gotten here define for the node SolidFire.Balduf.localdomain, an account and volume. You can see I've titled this account, the puppet device here so that we know this is coming from the device construct and then we've named volume dev dash volume so we know that also is coming from the device construct.
If we move down here a little bit we can see that I've defined a couple of variables. The URL is something you'll see me use a couple times here and this is basically a compound URL with a cluster admin account and password. Then the domain name or it could be the IP address of the SolidFire cluster. Then you'll see we use the SolidFire storage virtual IP address here also in this.
This is defining a node that is our client. You can see that's actually down here, it should come up and say client, yes it does, okay. As we walk down through this you can see I define a bunch of things here, some of these we'll use in various different spots. For instance volume names and volume access groups can't have dots so we'll replace them with dashes.
Then what we're going to do is we're going to go down through an we'll define an account, so we're going to go create an account on the SolidFire cluster. Then you can see here we are defining a volume on the SolidFire cluster. We'll continue down here we set up a volume access group, which we will include our actual initiator which we defined up above here. That's the initiator for our client. We will use the volume which we created above, so [inaudible 00:03:02] seen SolidFire volume is called back down here.
Then we're going to start exec'ing some commands on our client to show some real usage for this, right. We're going to go through and exec the [iscuzzy 00:03:14] discovery. We'll create a mount point, then we'll put a physical volume or a PE group on here. Make a volume group on that volume that we're creating. We'll create a logical volume here and then we'll go down, we'll make a file system and we will, so here's the [miking 00:03:37] the file system [XT4 00:03:38] and then we will make a ... we will actually mount the volume up.
This example shows how you could set up a ... and I'm going back up here in this ... how you could set up a manifest for a certain client, one of the servers in your network somewhere that needed to have storage for a database. We're hypothetically setting this up or mounting it to something called database, and then the rest of your Puppet manifest for this node could configure all the rest of the database [goodness 00:04:11].
Let's go over here and we'll start our master server. We're going to start it in verbose mode and we're not going to put it in the background so we can see the outputs that are coming out of it. We'll go down here to our client and what we're going to do is, I mean if all works well this should be not very entertaining, but that's why we do these things to make this all [auto-magic 00:04:42]. We're going to run Puppet agent, we'll run it in the test mode so it'll just apply it now, not go into the background and do it later.
You can see our server jumped up and said it was doing some things, so it's processing the manifest and sending that process manifest over to the client. The client's going down through here spitting out some message telling us it's ensuring things are created. You can see those at the bottom. At this point in time it's mounted the volume and it's creating the file system which takes a little bit of time here, and there we have it, we're done.
You can see it's set all kinds of good things but let's go see what we actually did. If we go and do a DF we can see that we actually have our database group logical volume mounted on mount database, but let's look into a little bit more of this. If we do this, you can see that there is our iscuzzy connection to the SolidFire. We've named things so again if we go over here to our manifest we can see, I named things SolidFire accountant name here was actually the fully qualified domain name of this client and that account name winds up right here in the string for the [IQN 00:06:12].
We can also go look at the SolidFire itself so you can see beforehand it had nothing there, when we refresh the volume screen you can see that we have a volume called client-localdomain-SDB and we can actually see the account over here. Once we refresh this and we get the account name, then we go back over here to volumes, we should actually get the account name to come up here in the volume screen also. You can see we've created a volume access group so we can go look at those in detail. It also has client.localdomain if we edit that we can see that it's got the volume in here and here's the actual IQN that we had up over here. It did everything we expected it to do and mounted up our volume. Again, it's not very exciting, there's not a lot that happens there unless it was a demo and Murphy were to show up.
Let's go look at the puppet device concept. The Puppet device concept is such that basically you have a different client, it's called Puppet device and it's a proxy for the network device. It allows us to go back to the server, so when we run it over here it will go over to the server, it will gather the information up, and pull that back. One of the things you'll notice up here is that in this manifest we had to put a URL. We put this URL that I defined up there in every resource that we define in here. When we look at the manifest for the actual network node you'll notice there's no login information. That actually comes from a file on this client, so if we do more of ... you can see there is a device file here. This device file gives us that URL. It has that URL all in that device file and it's there.
The challenge with this is that it's a separate client and it's going off and it's creating its volumes and it counts on the SolidFire but it has no relevance to this other client, so it could create that volume and the account and make it a volume access group but then we need a synchronization mechanism to go over to this client and have him mounted up. That's why we find the first thing I showed here a little more the Puppet agent and the Puppet agent talking to the SolidFire a little more useful but that has the drawback of every Puppet agent is going off to the SolidFire so if we have too many of those we may overwhelm the API capabilities of SolidFire. Having a single Puppet device would push all those API calls through a single host which would make it a little more manageable. Also could be some security issues in there too.
Let's see how this works. We basically use the Puppet command with the sub-command device. We point it at our Puppet server and so it too will go over. You'll see that the server over here on the left is doing some things. Its compiled a catalog, we've got some warning over there about a qualified domain name, but that's not really what we're looking for. What we want to see is if these two things here have been created. The magic has happened and there it is. We have an account called Puppet Device and we actually have a volume called Puppet Device.
A couple of other things you'll notice here in the manifest on both of these manifests we've put in apps so we're putting in the apps for that volume. You can see those come over here to the SolidFire managed accordingly, as it should be. One of the things that we can do now is we could modify this manifest and make this, oh I don't know we'll just make these something so that we can tell they're different and we'll write that off and now we'll apply this again.
Again, we'll see some stuff come out of our Puppet master here. This has happened. Of course we need to refresh this screen so we will do that, and you can see here that we've done our changes to the quality of service as requested by changing the manifest. Again, it's changing the manifest on the Puppet server.
One last thing, you can see we ran this twice and it did what it was supposed and now if we want to remove that volume we can change this to ensure that's absent. We can run this again and again it will go off and do it's thing, it doesn't show much but if we go back to our volumes and we refresh it here you'll see that it's gone. We obey the present and the absent commands in the manifest.
Hopefully that was a good demonstration of what the newly released Puppet modules for SolidFire can do. With that I will wrap up.