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