knife[:ssh_attribute] in knife.rb seems to be ignored

[tas50]

Version:

ChefDK 0.3.2

Environment: OS X 10.10

Scenario:

I'm attempting to ensure that knife ssh uses fqdn on my AWS nodes by adding knife[:ssh_attribute] = 'fqdn' to my knife.rb file.

Steps to Reproduce:

Run knife ssh name:* 'uname' -a fqdn and watch knife use FQDN to connect to the hosts
Add knife[:ssh_attribute] = 'fqdn' and run knife ssh name:* 'uname' and watch knife ignore the fqdn ssh attribute

Expected Result:

Knife should SSH to the hosts using FQDN

Actual Result:

Knife attempts to ssh to public IP on nodes using public IPs aka it ignores the fqdn attribute

[btm]

That's the current intended behavior, although it may not be the best. The last time I worked on this was in #1530 but I think the last time we discussed priority was in CHEF-4962 which was related to ssh port.

I believe the priority is, highest being the one used:

• knife cli argument
• cloud attributes
• knife config setting

If your knife config override your cloud attributes, then you would have issues in a mixed environment. It's easier to say "-a fqdn" than it is to do -a cloud.public_hostname (I'm not even sure if that separator or a works here), and you couldn't do a mixed environment that way. It seemed like this priority covered more cases that the other way around.

[Igorshp]

this change causes issues on vpn when public hostname has ports firewalled.
Feels little wrong to assume a public address is accessible and that this option cannot be overriden.

can the cli argument be set and forced in in knife config, similar to the old knife config setting?

[willejs]

+1 @Igorshp

[Igorshp]

For those afffected: 1.14.0.alpha.4 is the latest pre-change version that uses ssh_attribute correctly.

[smurawski]

Thanks for your thoughts on this @Igorshp and @willejs and @tas50. Given @btm's response that this is as designed, I'm closing this issue.

[lamont-granquist]

Feels like we really need a smart default here that would guess some priority of IPs and names and would try them until it found one that pinged and worked.

[Igorshp]

@smurawski i do not agree with this outcome. I belive the problem was originaly introduced in this commit 97cd18b

it made forcing the ssh to use specific attribute from knife config impossible. How is that a good thing?

I have submitted a PR with what I belive is the correct priority:

1. command line
2. knife.rb :ssh_attribute
3. cloud.public_hostname attribute
4. fqdn attribute

@btm what are your thoughts on this?

[btm]

IIRC, the current behavior is so you can configure an attribute for your local infrastructure in your knife config, and still use cloud instances which know the best configuration option for themselves, enabling you to use multiple clouds and local infrastructure without having to remember the correct attribute for all of them.

knife[:ssh_attribute] = "internal_address_of_doom"

If you have this configuration for your internal network, we change the default so that a knife config file setting wins over cloud attributes, and you go to use a cloud, you'll have to specify -a every time.

Another option for that case is having separate knife configs, which doesn't help you and @tas50 in your situation. Which is a valid argument for changing it.

@tas50 why fqdn? is your case like @Igorshp where something else in node[:cloud] would be more appropriate like local_hostname?