Default attribute for knife ssh in the clouds?


#1

Historically (since CHEF-922) when using ‘knife ssh’ to connect to an
EC2 system, you passed “-a ec2.public_hostname” to specify what
attribute to get the address from.

CHEF-1554 [1] proposes to use node[:cloud][:public_hostname] is
[:cloud] is populated. It currently falls back on
(Chef::Config[:knife][:ssh_attribute] || config[:attribute] || “fqdn”)
if cloud is not. I think this would prevent you from being able to
override, which isn’t acceptable. Provided that is fixed, what’s
everyone think about changing the default along the lines of this
proposal?

Bryan

[1] http://tickets.opscode.com/browse/CHEF-1554


#2

On 26/07/2012 20:14, Bryan McLellan wrote:

Historically (since CHEF-922) when using ‘knife ssh’ to connect to an
EC2 system, you passed “-a ec2.public_hostname” to specify what
attribute to get the address from.

CHEF-1554 [1] proposes to use node[:cloud][:public_hostname] is
[:cloud] is populated. It currently falls back on
(Chef::Config[:knife][:ssh_attribute] || config[:attribute] || “fqdn”)
if cloud is not. I think this would prevent you from being able to
override, which isn’t acceptable. Provided that is fixed, what’s
everyone think about changing the default along the lines of this
proposal?

Bryan

[1] http://tickets.opscode.com/browse/CHEF-1554
+1

Works for me as long, as long you can override it. As you say, being
unable to override would be a showstopper. It was bad enough not being
able to override settings from knife.rb.

Cheers
Nick


#3

Also +1


Denis Haskin
cell: 781-258-7414

On Thu, Jul 26, 2012 at 3:43 PM, Nick Peirson nickpeirson@gmail.com wrote:

On 26/07/2012 20:14, Bryan McLellan wrote:

Historically (since CHEF-922) when using ‘knife ssh’ to connect to an
EC2 system, you passed “-a ec2.public_hostname” to specify what
attribute to get the address from.

CHEF-1554 [1] proposes to use node[:cloud][:public_hostname] is
[:cloud] is populated. It currently falls back on
(Chef::Config[:knife][:ssh_**attribute] || config[:attribute] || “fqdn”)
if cloud is not. I think this would prevent you from being able to
override, which isn’t acceptable. Provided that is fixed, what’s
everyone think about changing the default along the lines of this
proposal?

Bryan

[1] http://tickets.opscode.com/**browse/CHEF-1554http://tickets.opscode.com/browse/CHEF-1554

+1

Works for me as long, as long you can override it. As you say, being
unable to override would be a showstopper. It was bad enough not being able
to override settings from knife.rb.

Cheers
Nick


#4

As long as you can override, +1 here. This often confuses people
starting out.

On Thu, Jul 26, 2012 at 12:49 PM, Denis Haskin denis@constantorbit.com wrote:

Also +1


Denis Haskin
cell: 781-258-7414

On Thu, Jul 26, 2012 at 3:43 PM, Nick Peirson nickpeirson@gmail.com wrote:

On 26/07/2012 20:14, Bryan McLellan wrote:

Historically (since CHEF-922) when using ‘knife ssh’ to connect to an
EC2 system, you passed “-a ec2.public_hostname” to specify what
attribute to get the address from.

CHEF-1554 [1] proposes to use node[:cloud][:public_hostname] is
[:cloud] is populated. It currently falls back on
(Chef::Config[:knife][:ssh_attribute] || config[:attribute] || “fqdn”)
if cloud is not. I think this would prevent you from being able to
override, which isn’t acceptable. Provided that is fixed, what’s
everyone think about changing the default along the lines of this
proposal?

Bryan

[1] http://tickets.opscode.com/browse/CHEF-1554

+1

Works for me as long, as long you can override it. As you say, being
unable to override would be a showstopper. It was bad enough not being able
to override settings from knife.rb.

Cheers
Nick


#5

+1 here as well.

Even if we drop the automatic cloud detection, implementing the ssh_attribute check via knife config would be super easy and DRY.


Robby Grossman
@freerobby (http://twitter.com/freerobby)
http://rob.by (http://rob.by/)

On Thursday, July 26, 2012 at 4:51 PM, Steven Danna wrote:

As long as you can override, +1 here. This often confuses people
starting out.

On Thu, Jul 26, 2012 at 12:49 PM, Denis Haskin <denis@constantorbit.com (mailto:denis@constantorbit.com)> wrote:

Also +1


Denis Haskin
cell: 781-258-7414

On Thu, Jul 26, 2012 at 3:43 PM, Nick Peirson <nickpeirson@gmail.com (mailto:nickpeirson@gmail.com)> wrote:

On 26/07/2012 20:14, Bryan McLellan wrote:

Historically (since CHEF-922) when using ‘knife ssh’ to connect to an
EC2 system, you passed “-a ec2.public_hostname” to specify what
attribute to get the address from.

CHEF-1554 [1] proposes to use node[:cloud][:public_hostname] is
[:cloud] is populated. It currently falls back on
(Chef::Config[:knife][:ssh_attribute] || config[:attribute] || “fqdn”)
if cloud is not. I think this would prevent you from being able to
override, which isn’t acceptable. Provided that is fixed, what’s
everyone think about changing the default along the lines of this
proposal?

Bryan

[1] http://tickets.opscode.com/browse/CHEF-1554

+1

Works for me as long, as long you can override it. As you say, being
unable to override would be a showstopper. It was bad enough not being able
to override settings from knife.rb.

Cheers
Nick


#6

Agreed. This confused me at first for sure.
CHEF-1554.num_supporters += 1

On Thu, Jul 26, 2012 at 4:59 PM, Robby Grossman robby@freerobby.com wrote:

+1 here as well.

Even if we drop the automatic cloud detection, implementing the
ssh_attribute check via knife config would be super easy and DRY.


Robby Grossman
@freerobby
http://rob.by

On Thursday, July 26, 2012 at 4:51 PM, Steven Danna wrote:

As long as you can override, +1 here. This often confuses people
starting out.

On Thu, Jul 26, 2012 at 12:49 PM, Denis Haskin denis@constantorbit.com
wrote:

Also +1


Denis Haskin
cell: 781-258-7414

On Thu, Jul 26, 2012 at 3:43 PM, Nick Peirson nickpeirson@gmail.com wrote:

On 26/07/2012 20:14, Bryan McLellan wrote:

Historically (since CHEF-922) when using ‘knife ssh’ to connect to an
EC2 system, you passed “-a ec2.public_hostname” to specify what
attribute to get the address from.

CHEF-1554 [1] proposes to use node[:cloud][:public_hostname] is
[:cloud] is populated. It currently falls back on
(Chef::Config[:knife][:ssh_attribute] || config[:attribute] || “fqdn”)
if cloud is not. I think this would prevent you from being able to
override, which isn’t acceptable. Provided that is fixed, what’s
everyone think about changing the default along the lines of this
proposal?

Bryan

[1] http://tickets.opscode.com/browse/CHEF-1554

+1

Works for me as long, as long you can override it. As you say, being
unable to override would be a showstopper. It was bad enough not being able
to override settings from knife.rb.

Cheers
Nick


#7

Ah, sorry for the double response. I got an error from the list that
my response wasn’t accepted the first time then didn’t see it show up.

On Thu, Jul 26, 2012 at 5:07 PM, James Light j.gareth.light@gmail.com wrote:

Agreed. This confused me at first for sure.
CHEF-1554.num_supporters += 1

On Thu, Jul 26, 2012 at 4:59 PM, Robby Grossman robby@freerobby.com wrote:

+1 here as well.

Even if we drop the automatic cloud detection, implementing the
ssh_attribute check via knife config would be super easy and DRY.


Robby Grossman
@freerobby
http://rob.by

On Thursday, July 26, 2012 at 4:51 PM, Steven Danna wrote:

As long as you can override, +1 here. This often confuses people
starting out.

On Thu, Jul 26, 2012 at 12:49 PM, Denis Haskin denis@constantorbit.com
wrote:

Also +1


Denis Haskin
cell: 781-258-7414

On Thu, Jul 26, 2012 at 3:43 PM, Nick Peirson nickpeirson@gmail.com wrote:

On 26/07/2012 20:14, Bryan McLellan wrote:

Historically (since CHEF-922) when using ‘knife ssh’ to connect to an
EC2 system, you passed “-a ec2.public_hostname” to specify what
attribute to get the address from.

CHEF-1554 [1] proposes to use node[:cloud][:public_hostname] is
[:cloud] is populated. It currently falls back on
(Chef::Config[:knife][:ssh_attribute] || config[:attribute] || “fqdn”)
if cloud is not. I think this would prevent you from being able to
override, which isn’t acceptable. Provided that is fixed, what’s
everyone think about changing the default along the lines of this
proposal?

Bryan

[1] http://tickets.opscode.com/browse/CHEF-1554

+1

Works for me as long, as long you can override it. As you say, being
unable to override would be a showstopper. It was bad enough not being able
to override settings from knife.rb.

Cheers
Nick