[chef] Re: Re: Re: Re: Re: A case for 'run once' recipes

[Arjuna Christensen < >]

Yo,

On 24/09/2009, at 12:48 PM, Brian O'Rourke wrote:

On Wed, Sep 23, 2009 at 5:10 PM, Tim Uckun < "> > wrote:

Idempotence is the prevailing paradigm amongst tools like chef but

personally I think there is a case for a "migrations" paradigm. IMHO
building and maintaining a server is not that different than building
and maintaining a database.  You start with the initial schema and it
evolves as time goes on.

The Rails-style database migrations you're referring to are an effort to effect idempotence for database schema changes. You migrate your schema once, and the changes that need to be applied are applied. When you run 'migrate' on a fully up-to-date schema, nothing happens because your migrations have already been run. Idempotent system changes are not at odds with systems evolving over time, nor are they at odds with processes being run only once (but you are responsible for keeping track of what's been run, at least at present).

Technically under the hood the majority of our resources and providers are migration-style, yet the DSL you declare desired state in has no concept of a migration - it is just a target.

service "foo" do

  action: start

end

On a system with the service 'foo' stopped, this will start it; while running, it will not. File and Template compare checksums of content [when applicable]. Other resources do not have any built in idempotency - guards must be added via only_if or not_if.

If you *really* think you need this behaviour, leveraging a simple bool node attribute will suffice:

if node.crazy_app.do_crazy_stuff

  all_vhosts.each do |vhost|

    remote_file "/etc/apache2/sites-enabled/#{vhost[:server_name]" do

      source vhost[:server_name

    end

    ...

end

Toggle it via attributes, a Role, the webUI/API or a JSON override file

Regards, HTH!

-- 
Arjuna Christensen, Software Development Engineer
Opscode, Inc.
E:  ">