Improved Bootstrapping

[janatzend]

No initial API Key Name/Secret has to be set in attributes before bootstrapping. Random key and secret specifically for Chef is generated and used in this recipes for restarting Zend Server and for joining Zend Server to the cluster. API Key is stored in node's attribute list. If a node joins a cluster and is not the first node, the API key in the attribute list will be overwritten by the cluster API key.

[janatzend]

@mkherlakian the idea was to provide an independent WebAPI user for Chef,
so that you can see for example in the Audit Trail what has been done by
Chef and what has been done manually. Additionally I heard several times
the request, that the hosting team wants to have a different key than the
guys who are for example deploying the app. Furthermore there is no need to
create and set an API secret at your own (reduces the risk of a failing
bootstrapping)

1 - the random key is stored after the first run and is not overwritten by
any subsequent runs. Could you please explain where I'm losing idempotence?
I don't see a difference to the current solution...
2 - I did not test with chef-solo, but with client/server setup. The API
key of the first node added to the cluster will be the new master key. The
second and all following nodes can join a cluster themselves with their own
random API key and the master API key will be returned by WebAPI. This key
is then stored as an attribute of the node.

2014-01-29 Maurice Kherlakian [email protected]

@janatzend https://github.com/janatzend do you think it's a good idea
to generate the key on the fly? The problem that I have with this is that
it's not necessarily idempotent in all situations, so 1- if you reprovision
and the key is not specified, the unit test will fail. 2- in a clustered
scenario chef-solo will not provide the right key to the other servers.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2#issuecomment-33541579
.

[mkherlakian]

@janatzend reviewed the PR - the idea is good I think but will only work in a Chef Server/Client environment. Most cloud vendors tend to use Chef solo (at least Rightscale and AWS Opsworks do) it would be great therefore if you could check if a key was manually provided, and if not then generate and store in the node's config.
Another point, maybe we need to do some research on this, I remember reading that it's not a best practice to depend on an application-generated value when converging. I'll have to dig that one up again. Also, would the generated value that you store for admin key name/secret survive a Chef server restart?