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

[Zac Stevens < >]

On Thu, Oct 4, 2012 at 12:43 PM, John Vincent
<
 >
 wrote:
> Yeah I'm not a big fan of calling node.save myself. The problem is
> that you HAVE to do it in several places. The mysql cookbook is a
> really good example. This wasn't an issue until the node.save was
> moved to only happening at the end of a successful first run. But in
> the case of the mysql cookbook, the problem is that if the initial run
> of mysql::server fails, it's impossible (or almost) to recover from.
> The install was done with a preseeded randomly generated value for the
> passwords on debian clones. There's no way to rerun that cookbook and
> have it pick up where it left off if it fails at some point during the
> run of the mysql::server recipe unless you save the node attributes
> right after you generate that random password.

As an aside... I've never been comfortable with recipes storing
autogenerated passwords as node attributes.  In this particular
example, I'd like Chef to bring up the database, then create database
users with credentials I've supplied in encrypted data bags.  I
neither need nor want superuser credentials to be stored in the clear
elsewhere on the network.

Besides generated passwords, what else might a recipe want to record
for later reference?  I'm struggling to find good examples.  In my own
chef-repos, the only real example is Venda's ssl_certificate
resource[1], which stores generated CSRs in node attributes.  Data bag
items would have made more sense, but doing this on the open-source
Chef server would have involved all nodes being admin clients.  Making
that resource work with chef-solo would involve something to ship CSRs
from nodes to a central location, at which point it wouldn't be a big
deal to have the resource write out to disk itself.

We might also consider Dan Carley's "Unautomating With Puppet"[2]
post, which makes a case for keeping some local state to help the CM
tool detect when it is being asked to make a dangerous change.
Implementing this in Chef would involve saving state apart from node
attributes.


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?


Zac

1: https://github.com/VendaTech/chef-cookbook-ssl
2: http://dan.carley.co/blog/2012/10/01/unautomating-with-puppet/