The Puppet Master Cometh
| Topics: | Uncategorized |
|---|---|
| Tags: | |
| Share: |
Last week Luke Kaines, The Master of Puppet, held a very well attended Puppet Camp here in SF. He drew a fantastic attendance from top notch companies - I was most impressed with the technical quality of the presentations and breakout sessions ( quality food too! ). These types of events can often be mundane or boring - this was not. Kudos to Luke for building a quality community.
I had the pleasure of meeting Luke some three years ago back at a BayLISA event where I saw him win over a tough audience with an early incarnation of Puppet. Its been fun watching him over the years deliver on that early promise and for continuing to win over a very tough crowd.
Recently I’ve been polling our customers how they do configuration/change management. Interestingly, I have noticed people mostly fall into two camps:
- A very large percentage that use Puppet
- A equally large percentage use nothing or home grown
It caught me off guard that such a large number use Puppet and equally surprised that there was no #2 vendor solution. Great news for Luke and team.
As part of my inquiry I’ve been compiling a list of integration points between Splunk and Puppet. Soon I’ll be dropping a Puppet App for splunk with dashboards, saved searches, and reports, based on indexing puppet reports, logs and facts.
- If anyone out there uses Puppet and would like an early copy or has integration ideas let me know
- If anyone out there does not use Puppet, they should look into it, and feel free to ping me if you have any questions, maybe I can point you in the right direction
Drop me a line for either - erik at splunk dot com.
Congratulations again to the puppet master Luke and his team for building one of the most exciting pieces of IT software in a long time.
October 23rd, 2009 at 12:27 pm
Erik, you might check out Nigel Kersten and his weblog/site for more info on Puppet. I believe he is one of the Puppet Masters. http://explanatorygap.net/category/puppet/
October 27th, 2009 at 4:09 am
There’s something else Splunk could get from Puppet: ideas for configuration syntax.
Splunk 4 overextends INI syntax by putting extra syntax inside stanza names like [host::nyc*], inside key names (MORE_THAN_80 or REPORT-) and inside key values (LOOKUP-foo = mytable userid AS myuserid OUTPUT username AS myusername)
Two years ago 2007 Splunk did some soul-searching on layered configuration.
http://blogs.splunk.com/rob/2007/10/02/software-configuration-why-does-this-wheel-need-re-invention/
The problem is that configuration is domain-specific, and “using XML” really means “building a DSL around XML syntax”. Splunk just chose to abuse INI syntax for its DSL instead of XML syntax.
I think that Splunk looks constrained by INI syntax and could do more with a Puppet-like resource syntax. See http://reductivelabs.com/trac/puppet/wiki/DocumentationStart. The language reference says “Resources are fundamentally built from a type, a title, and a list of attributes”
It would be declarative, human-read/writeable domain-specific language, two-way convertible with the more machine-readable YAML (or XML) representations. Might feel like:
extraction { “ip”:
regex => (?\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) }”,
}
props {”fooprops”:
extractions => “ip”,
check_method => entire_md5,
}
host { “*.foo.com”:
props => “fooprops”,
}
October 27th, 2009 at 4:33 am
Although, I would add that if everything Splunk needs can be expressed in hand-written extended-syntax INI files there’s no point in expending resources on a more general Puppet-like resource syntax (which may not event be a good fit for the Splunk domain). Another case of if it ain’t broken don’t fix it.
And it takes much the same amount of time to get used to an INI-based DSL as for any other (such as Apache, Puppet, or XML-based one).
October 27th, 2009 at 7:11 am
Or not. The puppet syntax describes resource and instantiates them, but each named resource of a given type must occur once only. Because the resource declarations are unordered, one cannot make a props{ “foo”: …} in two places with one overriding the other. This is unlike INI syntax where a stanza in one file can be made to override the same-titled stanza in another file.
May as well delete the earlier comments, the Puppet resource syntax won’t do for cascading configuration files.