Puppet » Puppet Dashboard

I personally think Vlad kicks Caps arse.

I’ll play with Vlad and see if Cap’s arse gets kicked.

Yes. It went to the dev list. Twice, IIRC. Let me know if you want it in any other fashion.

Igal Koshevoy wrote:

Julian: Thanks for posting your code to the mailing list at http://groups.google.com/group/puppet-dev/browse_thread/thread/33306df1200fc5

NP!

The code you posted is a start, but doesn’t seem complete:

Ok.

• Configuration files should survive a redeploy (e.g. database.yml).

Here’s what I pondered when writing this: Should we be doing this when we can never know what accurate configuration files would be? Someone has to create a database.yml that addresses the correct DB host with the correct credentials. I’m deploying database.yml.example as a stock file (that gets overwritten): it’s going to be up to the person to deploys the app to make sure that config/database.yml exists and is a symlink to a file that exists in persistent storage.

I can: – suggest a place to store the database.yml, – add an eycap (EngineYard’s custom Capistrano reciples) style task to create symlinks from that place, and – amend documentation to reflect this

Perhaps we could do the same for files like ‘config/environment.rb’ if the user had to change settings in there or in one of the environment-specific files (e.g. production.rb). But I’d think that we’d want these to default to the existing files to keep deployment simple.

• Deployment variables should be stored in a user-managed file, not one that’s managed by us through the version control system.

Agreed. Good call.

• Restart should be flexible, e.g. should not be tied to Apache, should not restart Apache, should not use hard-coded paths to OS-specific restart scripts.

Also agreed, with the same question as before: how far do we go in trying to anticipate a client deploy environment? Or do we just leave obvious symbols to change on the initial install and make sure that those things don’t get overwritten by a fresh deploy?

Here’s an example of a complete Capistrano configuration (deploy.rb) and sample deployment variables “stage” file (bridgepdx.rb):

• http://github.com/igal/openconferenceware/blob/master/config/deploy.rb
• http://github.com/igal/openconferenceware/blob/master/config/deploy/bridgepdx.rb

I plan to add support for #4605 “site-wide settings” in v1.0.5, which is the secrets.yml file mentioned by deploy.rb.

Great. I’ll take a look. Thanks.

We’re well into the release candidate stage of v1.0.4 and I don’t feel this is a feature warrants breaking the feature freeze to include, so we can complete this work at our leisure in v1.0.5.

Agreed. It’s not worth rushing.

Thanks for your feedback, Igal. I’d be interested in your opinion on the questions above.