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

[John Vincent < >]

Hey all,

Fletcher Nichol, Timberlake (jk) and I were bantering back and forth
on the twitters originally about the mysql cookbook blowing up on
failed initial runs on chef-solo (all related to the preseeded
passwords). Fletcher evidently has a PR coming about explicitly
failing out on chef-solo unless you specify all the passwords in your
node json. That's a bit of a different discussion. What I wanted to
noodle out is the possibility of a chef-solo friendly node.save. There
were few options that came up:

- Write back to the node json used during the call
- Write somewhere else to disk

The first one is fraught with edge cases and violating expectations
when mutating that file. What if it's under version control? What if
it's immutable in some way? The list goes on. I think we can sort of
agree it's a bad idea. So the second one came up. My thought is that
node.save when called under chef-solo should dump the node attributes
to the cache path as something like node-data.json (or possibly
something a bit more identifiable if you want to utilize the node data
between chef-solo runs on other nodes.

I realize that chef-solo will never replace server. I don't think
Opscode would have objections to community-originated PRs for adding
some kind of functionality like this? It would, however, allow us to
unify how we create recipes that are friendly to both solo and server.
It also has, as Ranjib Dey pointed out on twitter, immense benefit to
the various testing initiatives out there.

I'd also like to bring up a use case for reference that we have at enStratus:

Much like OPC (as I understand it), we use chef-solo as our
"installer". enStratus is fairly modular and while the default mode of
installation is to collocate everything on a single machine, obviously
that doesn't work. We typically support a single, two and four node
configuration of our stack for customer installs. Right now we use a
bit of a wrapper script and some manual error-prone data editing to
perform the two and four node installs. What would be nice is if we
could choose to persist node data between runs - primarily because of
the mysql cookbook thing - but also because we need to track some very
simple things like the mysql server IP but some passwords and
encryption keys. I having each node's data persisted to
cache/node-state/node{1-4}.json and loaded would be a godsend for
making these things more idempotent.

Anyway, just looking for feedback/thoughts.

Thanks
John E. Vincent
@lusis