I love the idea of Chef and Puppet. And to me, that idea is “let’s just declare everything we want to be true about a server and it can magically spring into existence.” Better yet, of course, is trying it out locally and then pushing it out, as Chef plus Vagrant promises.
Especially that server is declared as “NGinX should be installed” rather than “download this file, copy it here, unzip and build it…” Chef and Puppet, each in their way, is a possible vision of that future.
Of course, right now they are not ready for casual use.
But Aren’t They Both A Few Years Old?
I started with Chef several years ago. It was a bit of a mess — significant changes like Lightweight Resources and Providers that were supposed to change everything and the rewrites that followed. Berkshelf, and then later its acquisition and significant rewrites.
Basically, a fair bit of churn and chaos. Just what you’d expect of a new idea that’s turning into something you can use.
Puppet, of course, was doing almost exactly the same thing with the Puppet 2 to Puppet 3 transition, modules and whatnot.
To be clear: each and every one of these is basically a good idea. Some day, when Chef integrates them nicely, I think it will be an amazing solution.
Is This Just Theory?
Right now, the problem manifests in ways like the fact that you can’t use the latest version of the build-essential cookbook (one of the very basic ones) with the version of Chef that comes with Vagrant — you have to figure out you need a different Chef version, and use one of several hacks or plugins to make it work. This isn’t really documented… You just have to figure it out.
Plus, many Chef cookbooks don’t yet support the new LWRPs, and many Puppet cookbooks don’t support the Puppet-3-style modules, and all kinds of things are broken because they’re “old” — often only six to twelve months out of date, but that’s already old.
There are still a lot of rough edges.
Chef and Puppet will both be amazing, given time. However, as a non-Devops person… You can expect that they’ll both be changing a lot for awhile, and that they’ll be unfriendly to casual users for awhile yet. Upgrades will remain painful, probably for at least another year or two.
And likely more.
I look forward to the future, when a well-written year-old tutorial doesn’t require three or four updates to work with recent versions of everything. And we’ll get there.
We’re just not there yet.
Isn’t it wonderful when you get to go in and clean things up? The best, for me, is when I’ve learned a lot in a year or two and I get to re-do an old crufty program or a badly-designed page with what I’ve improved at.
What have you gone back and fixed lately?
Of course, Quarto has kind of an intimidating “install me first” list. Here’s what I needed to do:
I got to skip installing Git. If you need to install it, be sure to install XCode as well, which probably needs to happen from the Mac App Store these days.
brew update, because I hadn’t in awhile.
Install Pandoc. The package failed, so I had to use Homebrew to brew install haskell-platform, then cabal update, possibly cabal install cabal-install and finally cabal install pandoc. Haskell-platform can take 15 minutes to compile. If you need to install a new cabal-install (it’ll tell you if you do), that also takes awhile to compile. You can keep going, though – nothing else on this list depends on Pandoc until Quarto itself.
Install pygments. For me, that meant first installing pip (easy_install pip), a Python package manager, then pip install pygments.
Install xmllint (brew install libxml2).
Download and install PrinceXML, the free version. Unpacked, ran ./install.sh.
Install xmlstarlet (brew install xmlstarlet).
Install fontforge (brew install fontforge).
I didn’t need to install Ruby or RubyGems. If you do — well, try to make sure you get Ruby 1.9 or higher. This step could be difficult if you’re not already a Rubyist. We’re working on it :–(
gem install quarto
Looks like I’m not the first to notice that Quarto takes some installing :–)
Also looks like Quarto wouldn’t be too hard to put together a Homebrew recipe for.
When I was taking the Motorcycle Safety Foundation class awhile back (it’s awesome!) they said something that stuck with me.
“None of you are good enough to hit your motorcycle’s limits, even with these little bikes. You’ll have to ride for years before you’re hitting the bike’s limits instead of yours.”
I’m close to 40. I will never again get smarter, quicker, or have a better memory. My brain has a performance curve — I haven’t hit the “descending rapidly” part or anything, but it doesn’t go up from here.
It has still taken many years to start hitting my brain’s limits. I just wasn’t a good enough operator yet.
Here’s the thing: if you want to meet Britney Spears, odds are good that Britney Spears doesn’t want to meet you.
If you’re Lady Gaga, then Britney Spears probably does want to meet you.
But if you say, “hey, I’m Lady Gaga!” and you’re not, that doesn’t work.
You have to go be Lady Gaga, out where everybody can see.
And then Britney may say, “hey, you seem pretty cool. Wanna hang out?”
Ruby lets you hook in and see (and change!) a lot of behavior of the core language. Methods, constants, classes, variables… Ruby lets you query them all, and change a lot about them.
These are just hooks — things Ruby calls in response to something happening. That’s different from, say, all the methods you can call to find our what’s defined and how — like instance variables, or method bindings, or…
Here’s summaries and links for all the hooks I could find (thanks to Google and StackOverflow!):