Sat, 04 Jul 2009
Baby Steps with Python
Thanks to the enthusiasm I've returned from EuroPython with (and the fact
I couldn't make it to OpenTech because of washing machine issues) I decided
to spend a little bit of time porting Nagios Webchecks to
python. As a use case it covers a lot of the functionality I need in my day
to day system scripts. The ability to specify command line arguments, read
a config file and interpolate a template file for output.
I'm no where near finished (and I need to spend a lot more time with Python
in a Nutshell before I'm going to feel comfortable) but there's been nothing
too horrible so far. Libraries returning tuples rather than lists still feels a
little awkward but I suspect that's just me being new to this. ConfigParser
seems to meet my current ini file reading needs (which are pretty simple) and Jinja2
looks like a decent template engine. Biggest personal bugbear so far is
that using % when printing a variable feels wrong ( print "Hello %s",
name feels a lot more comfortable than print "Hello %s" %
name and is a more common format across languages.)
I'll show the code to a co-worker or two on Monday and hopefully pickup some constructive criticism as they destroy my slightly too perlish attempt at python code.
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2009/07/04 18:30 | /python | Permanent link to this entry | This entry and same date
Fri, 03 Jul 2009
By Puppet or Package
At work we both build our own packages and use puppet to manage our
servers. While the developers package up their work in the systems team
we've moved more to deploying programs and their dependencies via
Puppet.
While it seems easier, and quicker, to do the pushing that way, at least for scripts, you lose the ability to track what's responsible for putting each file on the system. I'm probably already modelling the more complex parts of what would be in a package (such as services and cronjobs) in the module and thanks to Puppet I'm probably doing it in quite a portable way. Is this actually better than using packages? It's certainly easier than building complex packages but it quickly gets awkward when you start needing to deploy compiled binaries or apps with lots of moving parts.
For now my rule seems to be - use puppet for small, non-compiled, apps and package up anything with lots of dependencies or that needs to be compiled. How do you deploy your infrastructure scripts and supporting artifacts?
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2009/07/03 22:12 | /sysadmin | Permanent link to this entry | This entry and same date
Thu, 02 Jul 2009
EuroPython 2009 - Wrap up Post
Over the last week I've been up in Birmingham catching up with some old
friends and attending some talks at the little get together of around 450
Pythonistas that was EuroPython
2009.
This was my second Python conference. The first was PyCon 2008, which was so well organised (by many of the same team as this years EuroPython) that I was inspired to come back. And I wasn't disappointed. There were a lot of very good talks, some that have planted seeds that I'll have to come back and try to find the time to look at and some that showed me things I plan on using in the very near future (such as py.test).
The atmosphere was topnotch. Everyone seemed friendly, the speakers were approachable and after spending the evening with so many people working on so many things it was a pleasure to get back to the room and make sure I actually did something technical before bed.
It's a wonderful feeling to come away from a conference feeling motivated to try new technologies and all I need to do now is actually schedule some time actually write some Python code...
The organisers did a great job and I'll be back next year.
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2009/07/02 21:13 | /events | Permanent link to this entry | This entry and same date
Wed, 01 Jul 2009
dstat - a window to your system
When it comes to Unix diagnostics I was raised the old fashion way, with
iostat, vmstat and similar tools. However times change and tools evolve.
dstat, while not as
comprehensive as using all the tools one by one, provides a wide range
of system performance details in an easy to use package.
While it's useful enough in its default state there is even more
functionality lurking just below the surface. To see which other modules
are available (but are not enabled by default) run dstat -M
list. To add an extra module to the output use a command like
this one: dstat -a -M topmem -M topcpu
As part of my growing use of the tool I've started to write my own little dstat plugins. I was pleasantly surprised at how easy they were to write and deploy even with my basic python skills. While the memcached plugin was a proof of concept I've not needed much I've found the process count plugin to be very handy.
dstat is becoming one of the overview tools I use when investigating performance issues and it's worthy of a place in your toolbox too.
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2009/07/01 21:32 | /tools/commandline | Permanent link to this entry | This entry and same date
Copyright © 2000-2010 Dean Wilson
