/dev/oops

fiddyspence's blog

A Puppet Sysctl Type

A while back, I decided that I really needed to cut my teeth on writing some custom extension points for Puppet.  Functions and facts are all well and good, and do useful things (in fact, I already by that point had a function in Puppet stdlib with, like, tests and everything).

The time had come, you see, so write a custom type and provider to do something magical.  I’ve found that the barrier to entry to learning new things technological things historically has always been doing something useful with whatever the technology happens to be - ‘printf(“Hello World”);’ has never really really cut it as far as I’m concerned.

So, world, I’d like to introduce you to my puppet-sysctl module:  http://forge.puppetlabs.com/fiddyspence/sysctl

I think it’s pretty awesome - it manages current running values, values in whatever sysctl.conf you want to stuff them into and it also manages detects where the kernel, the config file and Puppet are out of sync.

My personal favourite use of it is to control swappiness in Virtual machines (this was driven out of a consulting job where increased propensity to swap in a virtual environment results in an exaggerated performance hit to the point where applications timeout waiting for swap)

  sysctl { ‘vm.swappiness’:
    permanent => ‘yes’,
    value     => ‘0’,
  }

Even the nice people at Vmware suggest that 0 is the right value here for swappiness on virtual linuxes…

It should also work on BSD, cue an update to the forge!

Happy sysctl-ing.

The Simple Things

I’ve had a week where I’ve been thinking, professionally at least, about expressing system configurations in terms of code.  The code is used at a high level to describe what the state of bits of an infrastructure should be.  There’s all sorts of other stuff going behind the scenes to actually make that code turn into reality, on but at the most basic level it’s been a game of describing what reality should look like in an abstracted way.

One of the tricks to doing this effectively is to make those configurations as dynamic as possible.  The code should  consume data from one or more sources, make decisions on that data and output sets of configurations accordingly.  As a technique, this isn’t that new - IT is built around the idea that depending on what you input, the output gets modified and different things happen accordingly.

The data that is consumed by, and fuck it we’ll call a spade a shovel and talk about a configuration management system, might come from various places.

You might have static data that turn into very specific bits of config - think database connection strings that consume passwords, or website vhost entries that have various different attributes.  The data you consume might be dynamic - something is happening over there in a smoke and mirrors kind of way, and lo your configuration management system consumes some data and decides that you need to magically deploy another widget because the widget farm is approaching some capacity trigger that means you need more widgets, dammit.  The data you have, it’s complexity and how you use it to drive your infrastructure will depend on what you’re doing.

One of the fundamentals of data is that if it’s bullshit, it’s going to be hard to use.  Bullshit data will cause you to spend a lot of time working out what the data is (think about a 2 year old banging that square peg into the triangular shaped hole) and then what to do with it.  If you’re going to use data to drive your configuration, don’t fuck you-of-the-future up by trying to be cute or clever with the data.  Classifiying systems by hostname is a common trick to consuming data whilst making decisions on what configurations to deploy to a particular node.  Having a robust, meaningful but flexible hostname convention that is both machine and human consumable starts to look really important - the days of naming systems after Star Wars characters, Tube stations or car models are steadily vanishing into the distance.

The moral of this story is that a hostname convention where:

- The first three characters are the TLA of some football league (to denote production or development)
- The next n characters (where n is a number you first thought of, subsequently wiped your arse with and then composted it for n divided by some fish moments) are the names of your first several pet hamsters
- The next characters is a single hex number (that corresponds to something that was never quite clear)
- The final 2 are numeric characters (that mean this server is number xx)

Is going to be difficult to code against (to say the least) and are going to consume a lot of brain power to remember what the fuck bpl(barclays premier league)flashthethird(we had several hamsters as kids which met variously sticky ends)A69 actually does.

In case you were wondering about what else I’ve been thinking about, non-professionally as it were,  I’ll give you the conclusion and save on the reasoning - Pizza on 2 days in a row is a bad thing.

Good and Bad

I get to see, as part of my day job, the outcome of generally quite technical people battling with instructions.  Typically those outcomes are bad - unless someone has had a spectacularly good experience with some instructions, you probably won’t hear about it - think here of the iceberg of people who complain, versus those who praise (typically customer service).

This set of thinking has resulted out of a week-plus long battle I have had with a set of (and I flatter it a little here) technical documentation for some open source storage software.  I’m not going to flame the nice people who failed to write it, or make it understandable, but I am going to write some things that I think make better documentation than the other sort.  As you might guess, some of these things have made me a little sweary at times.  I know.  Me.  Sweary.

Assumption is the mother..

S’true.  If you assume I know already what all the components of your application are, and you don’t write it down, what you’ve done is going to be meaningless to me.  If you don’t introduce your subject matter in a way that means it’s consumable, then it’s not going to be.  Consumable, that is.  I like consumption.

Validate your processes..

If you give me a list of steps to follow, I shall follow them.  I shall even cut and paste your code.  When it doesn’t work, I am going to think that you’ve done it deliberately.  Probably out of spite.  If I ever meet you, I will stab you in the face with a spoon and set you on fire.

If it’s broken..

Your documentation is an extension of your code.  No bugger is going to want to implement your code in a mission critical context if you can’t support it. Version control it.  Get people to submit bugs on it, and that way it will improve beyond your wildest dreams because the documentation is going to be written by the same people who will want to consume it.

Check Apache - everything has been documented to the nth degree.  You’d have to either be a moron, or recently descended from a uterus to be in technology and not know what it is, BUT THEY STILL TELL YOU.  Actually, they could tell you what HTTP is - there might be some TLA type recursion there, but I’m willing to forgive them, they’re probably nice people.

What I am proud of, is that the things above are things that we (not going to tell you who, all opinions etc) do already, and do them well.

Happy Old Days

It’s always a happy feeling when you find out that all that stuff you used to own and spent significant effort building turns out to still be happily turning the cogs and cranking out good stuff.

All hail then….

…the printsearch web interface to Active Directory, giving you all your local printers in a dynamic and if I might say so fashionable and corporately branded way.  Last touched sometime in 2007, still going strong.

…the unique windows administrator password infrastructure (build painstakingly in vbs, with a client application, a server application and a pretty web interface to let you know how to log on to that stupid windows box that the idiot removed from the domain), untouched by human hands since 2007 and still churning out those passwords.

…the networked pdf print queue, delivering PDFs to your inbox for free since 2006 and still saving those Acrobat licences.

We hail you, and remark in passing what an excellent job it must have been to put them together that they might continue working unmolested and unmaintained.

I just hope they’re not lonely.

Comments

DynaRob
Helllllooooooooooooooooooooooooooo from http://www.dynamic-display.co.uk