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

[Sascha Bates < >]

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 | 

  | 
  |