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

[Jay Feldblum < >]

John, Alex,

Chef isn't really an interactive or back-and-forth conversation between recipes and the node data. The Chef model is much more linear than that.

As you know, the general Chef model is that you specify the whole abstract configuration (run-lists, node-data) up front, and then recipes just expand it out by declaring resources based on the abstract configuration, and then chef finishes the job by converging the server to match the declared resources.

If you need to generate a password during one run and save it on the server for use during the next run, you can use a simple trick as follows:

You can have a well-known password-storage file wherever you like (under /var/chef or wherever else you like). During the recipe run ("compilation phase") you can test for the existence of the file. If it does not exist, you generate a new password into a local variable and write it to the file (still during the "compilation phase"); that's what happens during the first run. If it does exist, you read the password from the file into a local variable; that's what happens during all subsequent runs. After that step, you can always copy the password into the node data, but of course now there's no longer any need to save the new node data, because it will always be recomputed exactly with the same deterministic input and with the same deterministic algorithm on every subsequent chef run.

Cheers,

Jay

On Wed, Oct 3, 2012 at 4:19 PM, Alex Soto < " target="_blank"> > wrote:

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
<lusis.org+ "> > 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