[chef-dev] Re: MySQL, chef-solo and node.save

Chronological Thread 
  • From: Sascha Bates < >
  • To:
  • Subject: [chef-dev] Re: MySQL, chef-solo and node.save
  • Date: Thu, 04 Oct 2012 07:21:25 -0500

On 10/4/12 2:14 AM, Zac Stevens wrote:
Given all that, I wonder whether we're defining the problem correctly.
  Is the real issue with node.save's absence in chef-solo (and its
consequences in chef-client), or is the "initial database password"
problem representative of a use case that wants for a different
solution altogether?

This is my thought as well. I've done a fair amount with Chef Server and Solo in conjunction with small projects and toolchains. I think chef-solo beats the hell out of a pile of shell scripts for managing an orchestrated environment install, but I think it's not the entire answer to the question.

No one can fangirl flail harder than I do over Chef and how much I love it. But Solo is not an orchestration tool and all the solutions I've been part of that use it in a toolchain have to do some hacky stuff to make it work. One of the things I'm seeing more of out there are orchestration tools that are tool aware, like Go and Maestro. But everything relies on an agent existing on your target servers, which doesn't address the initial bootstrapping where you might not have this.

For the specific issue of the password, addressing the ephemeral nature of proof of concept environments, I don't see anything wrong with pre-defining a plain-text password for things and either running follow up configuration management to update the password later or just not. It's a POC and should only be around to prove something out. If you really need to keep it around for a while, set up something to change the password after the install.

If it were me, and my customer's focus were already cloud-based, I'd have a private Jenkins, or Go or I hear Red Hat has a hosted orchestration service these days. I've also used Rundeck for this missing piece. I would use this tool to fill in the missing pieces where chef-solo wasn't meant to go. You could even have your last step be to create a cron job that deletes the orchestration agent 30 minutes after the end of a successful build if you want to cut ties with it.

Your orchestration should be as well thought out as your application and OS configuration strategy. If Solo is being used to configure servers, how are things being provisioned in the first place? Knife scripts? AWS shell scripts? I have a lot of thoughts on this because I've just spent the last couple of weeks working out how to set up CI to: create internal Openstack VMs and external RDS Databases, check out specific branches of code, build a project, run Chef on the VMs based on information passed in to the orchestration tool, and have several JBoss JVMs start up successfully. We're doing it with Jenkins and a target environment attribute with databags keyed to it.

When all you're using is chef-solo, everything starts to look like a chef-nail. But sometimes you need a bigger toolkit and adding a second tool to your repertoire will be less hacky, more beautiful and probably not take any more time to figure out than shoe-horning all your configs into chef-solo.

Ok, now I'm late for work. (officelife)

Sascha Bates | | 612 850 0444 | | |

Archive powered by MHonArc 2.6.16.