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

[Alex Soto < >]

I'm surprised that issue is still around.  I hit that years ago and
just ended up not using solo since.

However, I'd vote for writing to a 'new' json file and that the
original node.json and the new one are merged during the run  with the
new json overriding node.json.  That way the original is not messed
with and you have the final end result available as a json file for
future runs.

Alex


On Wed, Oct 3, 2012 at 12:51 PM, John Vincent
<
 >
 wrote:
> 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