[chef] Re: Re: Thinking out loud

[Miguel Cabeça <cabeca@ist.utl.pt>]

Hi,

* 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.)

Right now the metadata (json) is always "compiled" from the metadata.rb file. How about a default generated metadata file from the cookbook itself with overrides in the metadata.rb file? That way if I don't like the generated dependencies I can always override them in the file.

* 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.

Oh my... Another distribution system? Is it realy necessary? I always download the external cookbooks and customize them somehow turning them into site-cookbooks. Does anyone use third-party cookbooks without any modification? Maybe I just like to make it hard on myself :-P

* 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.

I don't understand this part, mainly because i don't know the meaning of the 'vendoring' word. Will someone be kind enough to explain this to me?

* 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.

I like this idea. I too want to keep certain node information on VCS.

* 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...

With a new distribution system comes a slew of features/problems that were adressed/solved over and over again by other distribution/package systems. Heck, why not just use dpkg for this  if you're modeling after it? :-P

Best Regards

Miguel Cabeça