Skip to content

Improved Bootstrapping #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Improved Bootstrapping #2

wants to merge 2 commits into from

Conversation

janatzend
Copy link

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
Copy link
Author

@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
Copy link
Contributor

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants