-
Notifications
You must be signed in to change notification settings - Fork 164
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
bootstrap_options are a Hash with symbols as keys #304
Comments
This is a breaking change, attributes are removed. This commit fixes #28 and #19. It generalizes the attributes so that other drivers can be used. It also removes the use of fog_key_pair and relies on the implicit management of SSH keys built into chef-provisioning or chef-provisioning-{fog,aws}. Specific changes follow: * Rename the ‘aws’ attribute to ‘driver’ and make it more general * Add with-parameter attribute to feed into the ‘with_driver’ method, allowing more general connection URIs for drivers * Add capability for installing and requiring chef provisioning driver gems * Update to use chef-provisioning-aws by default, changing the flavor_id attribute to instance_type, as that is handed off to aws-sdk * Add a new helper method #symbolize_keys_deep! that will convert the machine_options keys to symbols to work around an issue in chef-provisioning * Update README * Move “stash” directory to cluster-provision recipe * Adjust cluster-provision recipe to consume the new attributes changes * Adjust the setup-ssh-keys recipe to use chef-provisioning’s implicit key configuration It’s important to note that we must use the ~/.ssh/KEY location to get chef-provisioning’s automatic handling of the key, because when running in chef-client, it chdir’s to /, making ./.chef/keys unusable. If a key were created, it would get put into ~/.chef/keys, but we really want to have the keys created beforehand at this point in time. Issue in chef-provisioning regarding symbols vs strings: chef-boneyard/chef-provisioning#304
I talked with @jkeiser about this - we want to stop transforming objects that are passed as machine_options, bootstrap_options, etc. Right now we call |
Any further consideration of this? |
It does seem important: we should be able to accept node attributes with hash values in machine_options. @tyler-ball |
Any updates on this? Maybe I can help somehow? I would like to love to use Mash as machine_options or at least I would like to avoid converting node attributes to hash. |
When using node attributes to pass into
with_machine_options
,conditional tests that check, for example whether the bootstrap
options contains a key name, we have logic like this
Conditional checks in chef-provisioning use symbols as the hash keys.
This means that users cannot be assured that passing in the hash as a
node attribute in a recipe will get what they expect. For example,
chef-provisioning-aws has this conditional:
However, if I set my bootstrap_options as an attribute like this:
While
:key_name
is specified as a symbol, Chef actually turns thisinto a string since it's an attribute.
I can work around this by converting the attribute to a hash and then
walking the hash to convert all strings to symbols, but it would be
preferable that I can just shove my attributes into
with_machine_options
and it does the magic thing to work :).The text was updated successfully, but these errors were encountered: