| Puppet Camp 2009 |
[Oct. 4th, 2009|02:06 am] |
I have to say I've really enjoyed Puppet Camp. It's a reinvigorating experience, despite the jetlag, to meet up with smart, passionate and engaged operations people from all walks of life. My highlight really has been the people, and that's what I love about smaller unconferences is that you can meet everyone and everyone has something to contribute. Agile 2009 was great to go to, but I personally find I get more from smaller events.
I was happy to see the wide range of companies both in terms of size and domains who are using puppet and thinking about how to improve operations and systems engineering. San Francisco is an awesome city, and I've enjoyed finding some little havens of coffee drinking bliss, good food, fantastic cocktails and shopping heaven in my limited explorations so far.
Unfortunately I was a little nervous during my talk, which I'm pretty sure comes down to tiredness. I need to write up in more depth. For now here are my slides, video should be up shortly - I was really impressed by time to put up initial video by SFSU, and then them cleaning up the audio for the re-push.
|
|
|
| Agile Operations - Thoughts on Operations Testing |
[Aug. 19th, 2009|09:03 pm] |
When we talk about agile systems practices the subject of testing often comes up. In the development world practices such as Test Driven Development and Behaviour Driven Development provide a supporting practice to enable iterative development, make change safe (enabling refactoring), and provide a way to do just enough to deliver what is asked for.
It's important to look at why developers test in order to think about what the enabling practices in systems and operations is. For those not familiar with test-driven development Nat and Steve have a great introduction in their forthcoming book: http://www.mockobjects.com/book/tdd-introduction.html
I think about tests for systems administration in terms of what they provide both in terms of quality and confidence. Coming up with the right language to describe testing for operations is hard.
I've seen a lot of development teams internally struggle with the naming of what Nat and Steve call Integration Tests and Acceptance Tests (Functional Tests, Customer Tests, System Tests). If we agree with the premise that testing types a certain level is desirable for operations teams then we should focus on what we achieve by that and a first step approach. It's also important to have a clear language that everyone can understand what you mean - so if your team is using Integration Tests to mean something specific, then don't use that language to mean something different in operational testing.
It's important to think about what the different test levels give you and how that maps to operations/systems engineering. Also we're hitting the fact you illustrated that testing and monitoring are conflated. For development internal quality of code driven by unit tests enables ease of understanding and ease of change. If we want to have a practice in operations that makes our intent clear and enables ease of change this is not monitoring. |
|
|
| Agile Systems Administration Slides from Manchester Geek Night |
[Aug. 7th, 2009|02:09 pm] |
I spoke in Manchester last night, it was nice to be back in the city I spent five years failing to get a degree in. It's the place I first started working in systems at the Faculty of Arts helpdesk, first exposure to gopher, lynx, usenet and the web, and where I installed my first Linux systems.
The venue was the Kilburn building and the area outside the room had displays of Baby which was nice.
The group was small and mostly dominated by sytems people, I felt it went better than my previous talk on this at skills matter - I was more focussed and I think the presentation was more polished. Following we went on to the SandBar for good beer and further discussion.
Thanks to ThoughtWorks for inviting me up and putting me up in Manchester.
( slides ) |
|
|
| Fosdem 2009 |
[Jan. 17th, 2009|10:31 am] |
I finally got organinsed and booked going to FOSDEM, I didn't get there last year and am looking forward to it. Hopefully get a chance to catch up with some people.
 |
|
|
| A new entry into the state driven config management field |
[Jan. 16th, 2009|09:55 am] |
Whilst reading my daily blog roll I noticed that Ezra posted about a new configuration management tool chef and fact gatherer project ohai from the guys as opscode.
There is more details on the wiki, and I'm interested in finding out design differences to puppet and facter. An initial look at ohai looks good - JSON output of facts leads to clearer ability to collect nested facts than namespacing ipaddress_eth0.
chef looks to use ruby rather than an external dsl for it's cookbooks (recipes). |
|
|
| Capturing the intent of system changes |
[Nov. 4th, 2008|08:52 pm] |
There has been some discussion on the puppet lists about potential language shortcomings, something lak said echoed with some thoughts I've been having recently:
No one starts with code, even when they think they do -- you always
start with intent. Why are you building this node? What services
should it offer? Why?
In Test Driven/Behaviour Driven Development projects I see intent and goal extensively within the language of the tests.
Time and again when I see setups with systems in a state where their configuration is divergent and it's impossible to tell what is the desired state (if you haven't heard of puppet - check it out) and why the change was needed.
Take for an example an organisation using NFS or Samba as a backend store for documents for a distributed workflow. Tweaks to the config (kernel parameters, mount options, config changes) may be apparent from the system or puppet, but it may not be clear the underlying value that you're trying to achieve. It may be throughput, reliability, access - systems changes are usually made for a specific reason - I'd like to be able to more easily capture that (preferably in the format of executable tests to validate) but make it easy for Jo, the Sysadmin, to easily do as change is driven out either in reaction to a situation or as part of a planned change. |
|
|
| Systems Administration must die, die, die |
[Jun. 1st, 2008|03:06 pm] |
I really think that the term "Systems Administration" needs to go away. Use Systems Integrator, Systems Engineer (or Systems Reliability Engineer if you're Google) or some other term that more accurately represents the role.
I know there has been a lot of discussion about DSL's and Polyglot Programming around (eg http://ola-bini.blogspot.com/2008/05/new-hope-polyglotism.html), but I know that good Systems Engineers regularly context switch between different DSLs (config file syntax, puppet) languages (shell, batch, sed, awk, perl, python, ruby, powershell).
From my own experience I might be debugging a core dumping application using gdb, then swapping puppet update something, followed by a dash of shell, a sprinkling of graphing in gnuplot (or gruff and ruby), then some Java. I don't think the word administration even comes close to explaining that.
I don't hear the term "Operator" in common usage for Systems Engineer, and I'd like to see Administrator go the same way. If you're recruiting for people think about the fact that words are powerful, think about the role and what it involves, then see if you feel that Administrator is the word you'd choose to fit that.
If you don't know what your friendly neighbourhood Systems Integrator does, ask her if she would mind you shadowing for a day, if you're developing you probably will learn a lot about how to write applications that are supportable just from understanding the pain points of debugging with just a log file! |
|
|
| Tool of the day |
[Feb. 19th, 2008|05:43 pm] |
I was looking for something to simulate delay and latency on linux using netfilter or iptables and discovered Netem and the wonderful lagfactory script that did just what I wanted. |
|
|
| Puppet and ctags |
[Feb. 11th, 2008|09:01 pm] |
Whilst finding my way around puppet, I realised that some of the tools I'm used to when developing in other languages weren't quite there.
A quick read through the ctags documentation and I knocked up a couple of simple regular expressions that enable me to quick navigate through a large, split out puppet configuration using vim. Adding the following to ~/.ctags will enable you to run ctags -R at the top of your puppet manifests and navigate through tags. I'll probably need to actually go through the language definition and ctags docs some more to provide more comprehensive functionality but this works for me right now so I wanted to share it.
--langdef=puppet
--langmap=puppet:.pp
--regex-puppet=/^class[ \t]*([:a-zA-Z0-9_\-]+)[ \t]*/\1/d,definition/
--regex-puppet=/^site[ \t]*([a-zA-Z0-9_\-]+)[ \t]*/\1/d,definition/
--regex-puppet=/^node[ \t]*([a-zA-Z0-9_\-]+)[ \t]*/\1/d,definition/
--regex-puppet=/^define[ \t]*([:a-zA-Z0-9_\-]+)[ \t]*/\1/d,definition/
|
|
|
| Virtualisation libraries |
[Feb. 4th, 2008|10:06 am] |
Whilst looking into the progress of libvirt and use with VMWare and OS X, I discovered ivi which is a java library around VMWare, Xen, KVM and OpenVZ. Hopefully VMWare in libvirt won't be far off. |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| [ |
go |
| |
earlier |
] |
| |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
nasrat's journal