[chef] Re: Thinking out loud

[Adam Jacob <adam@opscode.com>]

On Fri, Jul 24, 2009 at 12:58 AM, Graeme Mathieson<mathie@woss.name> wrote:
> I've been messing with Chef for the past week and this morning I wrote out
> some notes on our private wiki about things I'd like to enhance/do. This is
> totally off my head and some of it is almost certainly as a result of
> missing out key bits of understanding.  After writing it, I figured, why not
> share it, so here goes:

Thank you so much for sharing this, especially with as much detail and
as raw as it is.  Awesome feedback.

> * Some sort of rspec/test-driven mechanism. At the very least, this should
> properly sanity check all the cookbooks, looking for typo'd attribute
> hashes, missing recipes and logic errors. I'm thinking that this could be
> built fairly simply just by stubbing parts of the framework and running each
> of the recipes. Second goal: get autospec working for it. Third goal: rspec
> matchers suitable for chef.

We agree!  The current plan here is to use Chef's own cucumber
features, along with some nifty scaffolding, to perform integration
tests for cookbooks.  I'm on the fence about the utility of unit
testing them - mocking out the responses from the Operating System is
brittle... but I'm happy to be convinced.  Some progress has been made
towards this goal already, and we would all love the help.

> * Remove the needless verbosity of the attribute definitions, like creating
> new Mashes, and only defining attributes unless they already exist. It's
> just messy.

Agreed.  Syntax suggestions?

> * Remove the duplication in the metadata.  While enhancing the attribute
> definitions, tweak them so that they include enough information to allow the
> metadata to be automatically generated. Dependencies can be calculated
> instead of specifying them manually.

Yeah - my only concern here is that there are going to be situations
where the calculated dependencies can only be done at runtime (think
having an array of recipes to include, for example)... so while we
should put some more smarts in, we need to make sure you can always
tweak the results by hand (and not have them blown away when the
automated process swings by.)

> * Allow cookbooks to be distributed as gems with gem dependencies on other
> cookbooks.

We're working on cookbook distribution very soon - it would be cool to
have a mechanism like this.

> * Allow vendoring of these gems, because I don't like relying on system
> gems, even in this sort of environment. Bootstrapping is key.

That is essentially what you have now with a normal chef repository -
I imagine the vendoring process would be very simple.

> * Get rubigen to have generators for an empty repo, individual cookbooks,
> that kind of thing.  In general, make the repo infrastructure feel more like
> a Rails app, just because that's a good example of an app development
> environment.  Individual recipes can be generated with: {{script/generate
> recipe ruby/gems}} which would automatically create the 'ruby' cookbook too,
> if it doesn't already exist.

Using rubigen to replace some of the custom Rakefile logic we use now
is a good idea.  File a ticket?

> * A thin bootstrap tarball of chef solo that doesn't rely on anything other
> than ruby being installed on the client system. No rubygems, nowt. That way,
> we can handle everything else through chef and have real bare-bones system
> images.

This would really just be enough chef to get chef - which is pretty
much the situation now.

> * Some sort of external, persistent information about nodes as well as roles
> in the repo. I kinda want the chef server to be easily replaceable, and
> everything about our infrastructure to be in version control. I can't quite
> see how to do that with nodes yet, but perhaps I'm just missing something.

Yeah - we actually have the code to do this basically ready, we just
need to rig it back up.  I imagine this will re-appear in the near
term future, and be very similar to the way we deal with Roles.

> * Bootstrapping a node from a pristine image, pulling all its information
> from an external system. I'm (so far) not liking the idea of creating a node
> by passing in some JSON when it boots. It should boot then get that
> information from a persistent store so that, next time it's imaged from
> afresh, it can start back where it left off without me having to separately
> document the JSON is was passed in on bootup. I think this is a repetition
> of the previous point. :-)

You can put an URL in for the JSON and the Tarball, allowing you to
build this system easily.

> * The equivalent of dpkg's "Provides" for providing alternative
> implementations of packages. Say, for example, I have a
> ruby_enterprise_edition cookbook, which {{provides "ruby"}}. If another
> cookbook says {{include_recipe "ruby"}} and we've already seen
> ruby_enterprise_edition, it will satisfy that dependency.

Hrm - that's an interesting one.  Right now you could have two
cookbooks, which both provide a "ruby" recipe, one that install REE
and one that uses the system ruby.  The metadata would be what
differentiates them, and things would work correctly.  I hadn't
thought about allowing cookbooks to essentially declare an alias...

> * Percona's build of MySQL [http://www.percona.com/mysql/5.0.82-b16/deb/]

Good idea!  That should be an easy one.

> * RabbitMQ

We'll have RabbitMQ cookbooks soon, if you don't get to them first.

> * Variants of all the existing recipes that don't use runit! (What can I
> say? I like consistency, and having a mixture of init.d and runit services
> isn't consistent. And out of band monitoring with God is easier than
> shifting *everything* across to runit...)

Feel free to fork. :)

> * Nanite infrastructure.

Coming soon.

> * Rolling out software updates (in particular, package security updates) in
> a timely manner across our infrastructure, after having tested on our
> staging infrastructure.

You can do this now with Chef, and when a nanite agent is broadly
available, trigger it into a more complex workflow.

> * Upgrading an EC2 instance to a bigger instance type. Automagically.

Should be easy, as long as all the persistent data is on an EBS store
and all the ephemeral stuff comes from Chef.

> * An overarching DSL for describing our infrastructure, from which all the
> node stuff is generated and deployed. What I'd *like* to do is "draw" our
> infrastructure in Graphviz dot notation and for that to turn into physical,
> working, connected infrastructure. That's my nearly-end-goal.

We're working on this - not in Dot, but in general.  Check out:

http://wiki.opscode.com/display/chef/Roles+and+Infrastructures

Thanks again for the great feedback, Graeme - glad to have you in the
Chef community!

Regards,
Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com