Mark Needham

I’ve been playing around with Chef Solo on Fedora and executing the following:

sudo chef-solo -c config/solo.rb -j config/node.json

(where node.json just contains the example code from the resolver example on the Chef documentation page and the cookbooks folder contains all the opscode cookbooks.)

leads to the following error:

...
ERROR: Running exception handlers
ERROR: Exception handlers complete
FATAL: Stacktrace dumped to /home/mark/chef-solo/chef-stacktrace.out
FATAL: ArgumentError: Attribute domain is not defined!

A bit of googling led me to believe that this error is happening because the machine doesn’t have a fully qualified domain name (fqdn) defined which can be seen by calling the following command:

$ hostname -f
> hostname: Name of service not known

One way to fix it is to add the following entry to /etc/hosts

127.0.0.1	mark-fedora

Which results in the script running fine with no errors.

...
INFO: Running report handlers
INFO: Report handlers complete

A suggestion I read while googling about fqdn was to add the hostname of the machine into a file called /etc/HOSTNAME but that didn’t seem to have any impact for me.

On the Mac hostname -f works fine even without an entry like the above in /etc/hosts so I’m not entirely sure how it all works!

If anyone could explain it to me that’d be awesome.

I’ve been flicking through Continuous Deployment and one section early on about changing configuration information in our applications particularly caught my eye:

In our experience, it is an enduring myth that configuration information is somehow less risky to change than source code. Our bet is that, given access to both, we can stop your system at least as easily by changing the configuration as by changing the source code.

In many organisations where I’ve worked this is generally adhered to except when it comes to configuration which is controlled from the database!

If there was a change to be made to source code or configuration on the file system then the application would go through a series of regression tests (often manual) to ensure that the application would still work after the change.

If it was a database change then that just be made and there would be no such process.

Making a change to database configuration is pretty much the same as making any other change and if we don’t treat it the same way then we can run into all kinds of trouble as the authors point out:

If we change the source code, there are a variety of ways in which we are protected from ourselves; the compiler will rule out nonsense, and automated tests should catch most other errors. On the other hand, most configuration information is free-form and untested.

Alex recently wrote about his use of deployment smoke tests – another suggestion of the authors – to ensure that we don’t break our application by making configuration changes.

Organisations often have painful processes for releasing software but I think it makes more sense to try and fix those rather than circumnavigating them and potentially making our application behave unexpectedly in production.

Jez recently linked to a post written by Timothy Fitz about a year ago where he talks about the way his team use continuous delivery which means that every change made to the code base goes into production immediately as long as it passes their test suite.

I’ve become fairly convinced recently that it should always be possible to deploy to production frequently but we recently came across a situation where it seemed like doing that wouldn’t make much sense.

The project involved replacing an existing website but rebranding it at the same time. One of the key goals of the project was to create a consistent brand across the whole site.

Therefore it seemed that if we chose to incrementally deploy to production then we’d need to spend some time updating the old website so that the look and feel was the same across both versions of the site.

The overall time to finish the project would therefore be higher and the value that we’d get from actually get from putting something into production early probably wouldn’t justify the extra effort that it’d take to do so.

In this situation the most effective strategy seems to be to still deploy as frequently as possible to a production like environment internally but only deploy to live when the whole thing is done.

If we’re replacing the backend of an old system and the end user won’t see anything different then an incremental deployment approach is certainly worthwhile but when brand consistency is the most important thing I’m not sure that it still makes sense.

As always I’d be keen to hear if anyone’s done anything similar and if there are any ways around this.