SolidFire Puppet Module

Share:

Yeah, you read that headline correctly! I’m here to announce that we have released a first take at a SolidFire Puppet provider and have made it available to the community. This version supports all of the appropriate puppet mechanisms (device, agent and resource) and has complete enough features that we can do something useful with it. I have written some starter documentation to go along with what we published and you can find the documents and code here,

Note: This effort to provide puppet modules is 100% community driven and supported as such through the community (i.e on the Forum on the SolidFire developer site) in a best effort manner. If you want to contribute, we will more than welcome your contributions. Please do not call SolidFire support.

Since we actually wrote some documentation, in this blog post I’ll take you through the example of how one would use it. We’re going to run this example in a full puppet master/slave environment, although we’ll apply it on demand (not scheduled like most people do). We create a manifest on the master, in this simple case, we’ll use site.pp (the main manifest) and define a single node (our client). In a large environment variables and code may be maintained in databases and source control and automatically pulled into puppet, we’ll skip that today. The manifest instructs the node to communicate with the SolidFire cluster and create the account, volume and VAG needed. Once the interaction with SolidFire is done the client will the necessary steps to discover the volume, format and mount the it through standard puppet modules available through the puppet catalog. The manifest is shown below (small) and can be found fully commented at the github site here.

SF Puppet1

When we run this manifest with the puppet agent command, the puppet agent communicates with the master to get a compiled and interpreted version of the manifest, the facts and the modules needed and run the manifest, then executes the manifest on the client. The client is in direct communication with the SolidFire cluster. The below screen shot shows how what it looks like, but frankly it’s kinda boring (which is the way it should be when it works).

SF Puppet1

As you can see it did what was commanded of it, created the volume and made it usable to an application. If you were using puppet to control a large implementation of database servers, you could use this to provide each of those servers with a volume from SolidFire for their database data. You could then modify the manifest(s) on the master and change all of their QoS settings (if you program this correctly you would have single variable, maybe in Hiera) and have them all get more or less performance as needed.

As you can image if a large number of clients were all calling the SolidFire APIs with the above manifest this could be a large load of API calls on the SolidFire cluster, so next blog post we’ll talk about the good and bad of the puppet device concept and I’ll also blog more about some of the advanced topics in the coming weeks. In the mean time, if you have questions, concerns or comments, please post them on the Puppet Forum on the SolidFire Developer site and I’ll see them and respond there.

Related Content