Skip to content
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

Closed
jtimberman opened this issue Mar 6, 2015 · 4 comments
Closed

bootstrap_options are a Hash with symbols as keys #304

jtimberman opened this issue Mar 6, 2015 · 4 comments
Labels
Triage: Confirmed Indicates and issue has been confirmed as described. Type: Enhancement Adds new functionality.

Comments

@jtimberman
Copy link
Contributor

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:

!bootstrap_options[:key_name]

However, if I set my bootstrap_options as an attribute like this:

default['driver']['machine_options'] = {
                      :ssh_username => 'ubuntu',
                      :use_private_ip_for_ssh => false,
                      :bootstrap_options => {
                                             :key_name => 'hc-metal-provisioner',
                                             :image_id => 'ami-b99ed989',
                                             :flavor_id => 'm3.medium'
                                            }
                    }

While :key_name is specified as a symbol, Chef actually turns this
into 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 :).

jtimberman pushed a commit to chef-boneyard/chef-server-cluster that referenced this issue Mar 6, 2015
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
@tyler-ball
Copy link
Contributor

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 .to_hash on those options (I think from here) which loses the ability to reference the attribute mash correctly. But because there is a workaround for this we are going to hold off until after the 1.0 release.

@tyler-ball tyler-ball added this to the Later milestone Mar 11, 2015
@jtimberman
Copy link
Contributor Author

Any further consideration of this?

@jkeiser
Copy link
Contributor

jkeiser commented Jul 7, 2015

It does seem important: we should be able to accept node attributes with hash values in machine_options. @tyler-ball

@tyler-ball tyler-ball modified the milestones: 1.3.0, Later Jul 16, 2015
@tyler-ball tyler-ball modified the milestones: 1.4.0, 1.3.0 Aug 12, 2015
@tyler-ball tyler-ball removed this from the 1.4.0 milestone Sep 10, 2015
@szymonpk
Copy link

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.

@tas50 tas50 added Type: Enhancement Adds new functionality. Status: Confirmed and removed Improvement labels Jul 31, 2018
@tas50 tas50 added Triage: Confirmed Indicates and issue has been confirmed as described. and removed Status: Confirmed labels Dec 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Triage: Confirmed Indicates and issue has been confirmed as described. Type: Enhancement Adds new functionality.
Development

No branches or pull requests

5 participants