Sometimes it’s the simplest things that remind me why I love the classic unix tools. Here’s a quick way to fill in cookbook_versions for a chef environment using awk.
Of course, this is a ridiculously simple usage of awk. There’s plenty more that can be done with just a single line of awk.
It seems in the chef community lately there’s a growing trend for cookbooks to be kept in separate repos, or even separate branches in a single repo. I wanted to share the script I used to split out the community-cookbooks repo for Heavywater
I knew the general git commands I needed to use, but it did take a few local trial runs to get it exactly as I wanted. To create the actual repos on github I made use of the excellent hub script.
While there’s definitely a more elegant way to do this, maybe you can use this as a starting point should you need to do the same.
There’s a rather thought provoking article by David Mitchell at The Guardian site right now. It’s relatively short and worth reading, and I say that even as someone who isn’t all that interested in the NHS project that frames the article’s opening paragraphs.
Mitchell makes two points that I found myself both agreeing with as a developer and sysadmin, and leading me to further thought. First:
Nothing sharpens the brain like a whetstone of tedium
In the context of our work tedium could be any number of things. For some it’s documentation, labeling cables, seemingly minor manual config changes made in production up or the ever present yak shaving in some form or another. A drive to erase this boredom or tedium has resulted in many of the excellent tools in use today, such as Chef, Puppet, and other powerful automation software. Repeated slogging through boring steps led someone to think “I can do this better”.
Of course, not all tedium is bad and needs to be eliminated. In programming there’s no substitute for the hours of typing code in an editor that improves your grasp of a language, the way repeated physical exercise hones the body. The ability to focus for increasing lengths of time on a given problem or task is a valuable skill. Ones mental acuity, that ability to concentrate, focus and understand, can be greatly improved with effort. These are valuable skills that improve over time, accompanied by some percentage of tedium, the way practicing scales may see to a new guitarist.
The second point Mitchell makes actually comes from Alex Hope, co-author of the recent Next Gen report: Coding is the new Latin. He is also quoted in a recent BBC news article by Rory Cellan-Jones
Computers are here to stay and yet for the most part many still view them as “an imposition, a distraction, something stultifying that dominates our lives but we somehow feel shouldn’t”. The way they are explained and taught is a perhaps a direct outcome of this, sometimes silently unacknowledged, viewpoint.
…even a rudimentary knowledge of Latin cuts down the labor and pains of learning almost any other subject by at least 50 percent.
Code needs to be the common language to teach people about the world we now live in. The perspective and understanding gained from learning to solve even a simple problem using python or ruby can give people a sense that these machines they now depend on are not so foreign or unknowable. It certainly does more than teaching them how to SUM numbers in a spreadsheet.
David Mitchell compared code as Latin for the assumed tedium, but I think it can be done better. Everyone should be able to at least read and understand the flow of some code.
One of the most intriguing things I’ve noticed about the devops movement is the emphasis on a culture of inclusion and instruction. This is one of the main reasons I enjoy being a part of it. Certainly learning to code is not generally an issue with people who are either in development or systems administration, but we need to continue to be better at instilling our love for what we do and why we do it in others. Not just within our culture or respective fields, but everywhere.
In a healthy organization no one should be content to just “throw code over the wall” or not think about how all the pieces fit together. We’re certainly working to change that, but it can go further. Everyone who touches computing resources in an organization can have a basic understanding of ‘what makes it tick’. They may never be driven to tinker and make changes on their own, but they can be helped to see and appreciate the inner workings in a favorable light.
We shouldn’t be keepers of some ivory tower but instead mentors and instructors, sharing excitement and understanding, the very thing we should already possess and that brought us to the field we are in. I believe teaching others to code and to understand code, even though they may not choose to do so themselves, can have a significant impact on their comfort level and enjoyment in working with the tools we use today.
One topic frequently tossed around at the recent Opscode summit was a re-org of the cookbooks repository. No more monolothic cookbooks repo on github, instead replaced by single cookbook repos, making it much easier to pull and contribute to a single cookbook.
@jtimberman will be leading this effort.
On a slightly unrelated note, it looks like @dysinger posted a handy little cleanup script:
The first historic Opscode Community Summit is officially over. See yesterdays post for a basic description of the event and structure.
After another brief introduction, topics were discussed, a schedule arranged and the agenda was live. Topics for day two included:
Managed Nodes a.k.a external entities
Chef for big data projects, such as hadoop, cassandra and similar
Ticket/triage process
Network monitoring, it sucks
Feature roadmaps, both short and long term
There’s more, but I lost track due to poor note taking on my part.
By far the biggest announcement to come out of today was the fact that Hosted Chef is moving from Ruby+NoSQL to Erlang+MySQL. For Opscode it boils down to using the right tools for the job and after a hard look at how Hosted Chef is being used it’s clear this change will be for the better. Erlang brings a ton of cool benefits and I look forward to hearing about their migration path from the current platform. Lots of nice performance graphs accompanied this discussion, led by Chris Brown and Kevin Smith from Opscode.
Sean Porter led a discussion about monitoring and the how the community is using the myriad of tools available to us. Basically monitoring is hard and has subtle challenges at scale in current implementations. He showed off sensu and discussed ways for possible collaboration with the community. I hope to dig in to this a little more since I’ve been thinking about problems in around monitoring, metrics and alerting for a little while lately.
Overall what I most enjoyed about the summit is the sense of community that is clearly maturing around chef. With so many passionate people and hard problems, there’s bound to be some neat things on the horizon. It’ll be exciting to see what the next year holds in store for Opscode and the chef community.
Check out further details on the individual sessions on the Opscode wiki
Opscode Summit day one has passed. I had to skip the sponsored dinner tonight, so for others it might still be going on. While there were lot’s of great sessions going on, and a great variety of people (seemed like 100+ in attendance), one thing stood out to me: The Chef community is awesome.
To be fair, there are many great tech communities but the advantage the chef community has, and devops culture in general, is how many different skill sets are necessarily brought together combined with a culture of friendliness. Networking gurus, SysAdmin fanatics and passionate Devs are all brought together to solve some of the toughest challenges in modern computing infrastructures.
The benefits from this variety of experiences are immediately evident with everyone brought to the same table, each one sharing their unique perspectives and experience. With so much to learn it’s great there’s so many experienced, friendly people to learn from.
The Community Summit is structured in an Open Space
unconference style, which is
a refreshing change from the usual conference agenda approach.
After a brief introduction attendees gathered to discuss the topics and sessions that would be discussed throughout the day. The resulting agenda board is pictured at right.
Throughout the day I especially like how the guiding idea of the Law of Two Feet was evident: If at any time you find yourself in any situation where you are neither learning nor contributing: Give greetings, use your two feet, and go do something useful. Responsibility resides with you.
This fosters a relaxed, self-learner friendly style of participation, which I felt lowered the social barrier for participation within the groups.
Personally I was able to attend the discussions on Cookbook syntax checking ‘Lint’ style, Management of External Entities, Documentation improvements, How to handle “tactical” or short-lived changes and the ‘Choose-your-own-adventure’ style talk by Adam Jacob.
Further details for the individual sessions are available over on the wiki: Chef Summit - Day One
I’m looking forward to the sessions tomorrow.