Feb 8, 2016 - How to break up chef attributes


So, if you are working with a cookbook, you may get to the point, where your default attributes file starts to look like an utter mess. As you add more options or configuration parameters, it gets harder and harder to sort what is going on in your attributes file. This is one of the reasons applications like nginx and apache allow for includes. In the same fashion, you can add additional attributes files, but by default you do not have access to them unless you include them in part of your recipes.

Ok, so let me take a step back and explain a couple of the reasons that you may want to separate out the attributes that you have in the default attributes file. For a large number of cookbooks, maintaining a single attributes file makes a lot of sense. However, there are situations where using multiple attributes files is an asset.

  • You have a large number of variables that need to be set
  • Some attributes are only needed under certain conditions
  • Passing values based upon an environment

After working on this for the past couple of days, it has become obviously clear, that the docs are a bit messed up. ANY FILE that is in the attributes file will be read. This makes it extremely easy to pull in values to be used. However, it does make it a bit more problematic for setting values based upon environments. That is really a small price to pay.

Instead of talking about how to pull them in, I am going to talk instead about breaking up attributes into files that make sense. This is extremely important. If you have ever had to parse through a 2000 line config file to find a setting, they you might understand my pain. So, if you have a cookbook that does a multitude of things, break the attributes up into small workable parts.

I am done, because there is nothing more to say, other than that Chef docs can make a person want to pull out his hair.

May 25, 2015 - Updating this jekyll site


This site has sat in a very unfinished state for the past year. This is due largely in part to the fact that I have a strong dislike for all things front-end related. That is not entirely true, but it is close enough to the truth. About a year ago, I decided to use Twitter Bootstrap for the layout and css for the site. I had used version 2.x of bootstrap in the past, and had liked it. Moving to 3.x was a mistake. Gone was the simple interface and examples, and instead I was left with documentation that I could not make heads or tails of, and a site that looked like crap.

So, 2 days ago I decided to dump bootstrap and go with something completely different. I started by doing a search for alternatives to twitter bootstrap. There were a number that popped up, but one that caught my attention was HTMLkickstart. Here I had found a bunch of elements that were easy to use and incorporate into my site. I will admit, that I used the default layout from HTMLkickstart to get rolling. I like how lightweight it is, and how easy it is to configure.

I did have some issues with syntax highlighting and code, but by removing the stylesheet that had code, I was able to get pre and syntax highlighting working. Jekyll also offers powerful support for code snippets, and I need that for the code I am going to be showing. Here is a test example below.

def print_hi(name)
  puts "Hi, #{name}"
#=> prints 'Hi, Tom' to STDOUT.

Now that I have at least the fundamentals of the site worked out, I plan on adding posts and information. The main site will change, but that will be used for storing data of a more permanent nature.

Sep 9, 2014 - We need to avoid complexity.


Complexity. Complexity is the enemy of good system automation. It is the bane of desiging a good application, and how the pieces work together. In the world of DevOps, the amount of convoluted designs that one has to deal with is normally equivalent to the amount of time that a person has been working in the industry.

It is easy to make a complex solution to look even more complex, but it is difficult to make a complex solution look simple.

That is the crux of the problem. There seem to be a large number of people that want to take a problem and find and eloquent solution. This solution is not simply the best or simplest, but it is eloquent. Simplicity can be frowned upon because it does not utilized the latest tools or buzzwords, and ours is a business of buzzwords.

What we need in the devops field is to look for the simple solutions to complex problems. This might mean skipping some ‘really cool’ technology, for the sake of having an environment that is maintainable and supportable. It does not matter how cool a tool is if you are not to where you need to be by the end of the day.

Keep It Simple

What am I getting at? I guess in the end it boils down to the following. STOP TRYING TO BE CLEVER. There it is. Keep things simple, or make them look as simple as possible. Any solution should be easily broken up into parts and explained. Now, there may be some code that adds a level of confusion, but that is neither here nor there. The key to a good devops environemt is to have one that you can introduce to a new person, and have the up and running very quickly.

The best example would be the use of Chef, Ansible, or the mix of the two. Once the environment has become so complex that best practices for either Chef or Ansible have to be skipped, then you need to step back and consider if what is being done is the best way to do it. Sometimes the desire is so high to use a specific tool, that more and more convoluted changes will be put in place. This does nothing good for anyone. It might be a good way to inflate an ego, but for the overall group, it is a loosing proposition.