Use machine_options[:ssh_username] for transport.

[miguelcnf]

Give precedence to machine_options instead of machine_spec when itcomes choosing the ssh username.

Also update the machine_spec with the machine_options value if transport is successful.

This replaces #45 with a clean commit history.

Should solve #44 and #51.

[jkeiser]

In general, we haven't been giving precedence to machine_options because keys can drift over time; but I'm leaving this open even though #65 was committed, because there is a real discussion to have on this point. I'm not happy at all with our credentials story, yet.

[jkeiser]

@miguelcnf for the moment I'm moving this one to Later since the primary issue (ssh_username is not honored) is fixed; but I still want to have this discussion. It seems to me that there are real tradeoffs either way--if you prefer machine_options, it becomes changeable (which is super good), and if you prefer machine_spec, then recipe drift won't break your ability to reach older machines (which is also good).

[jkeiser]

Closing this for now; we're still aware of it but not planning to merge this at the moment.

[poliva83]

@jkeiser Can we reopen this discussion?

chef-provisioning-aws today has implemented ssh transport (https://github.com/chef/chef-provisioning-aws/blob/master/lib/chef/provisioning/aws_driver/driver.rb#L948) in a way you can't update ssh_username on second convergence of machine node unless you actually delete the machine first. This is because machine_spec is higher precedence then what you set in machine_options. There seems to be no workaround if you desire to update ssh_username (and force 2nd chef-client run) without deleting your machine.

I'd like to have this converstation because we followed this same implementation for our chef-provisioning-opennebula driver. I don't really want to code our driver with different logic then chef-provisioning-aws since its the most popular driver.

[miguelcnf]

When I first wrote this I found it annoying but not a show stopper, I still look at it the same but in my head it makes total sense that machine_options have priority over machine_spec exactly for what @poliva83 described.

@tyler-ball let me know if you want me to look at this branch again and resolve conflicts etc.

[bbuczynski]

a use case to have machine_spec with higher precedence than machine_options would be if there is a single provisioning user that can deploy VMs (for example to prod) and nobody else should have access to those machines ... how about making it configurable? this is how I implemented unique VM names, fqdn enforcement, and stop method override in opennebula driver

[tyler-ball]

I don't think we should make the machine_options <=> machine_spec precedence configurable. It seems like adding a knob where we don't need one.

I think that machine_options should override machine_spec. It would be a breaking change so we would need a major version bump, but after documenting it I think it would make more sense to users. What you specify in your recipe should always take precedence over what has been stored in the background.