[chef-dev] RE: REVIEW: Ohai Cloud Plugin Improvements (OHAI-542)

[Jeff Mendoza < >]

As an answer to number 1. I'm fine with moving forward with 
node['azure']['ssh_port']. I didn't think this would be acceptable by the 
Chef community. I assume that node['cloud']['ssh_port'] would be preferable, 
as this is generic, and does not lock out any other could provider from 
filling that attribute.

Thanks,
Jeff

________________________________
> Date: Wed, 8 Jan 2014 16:25:08 -0800 
> Subject: Re: [chef-dev] REVIEW: Ohai Cloud Plugin Improvements (OHAI-542) 
> From: 
> 
 
>  
> To: 
> 
 
>  
> CC: 
> 
 
>  
> 
> Jeff, 
> 
> After doing more digging, I see what you mean about the single virtual 
> IP.... 
> 
> As you said, Azure has the concept of a "cloudservice"[1] which can 
> contain multiple VMs within it. These VMs are all behind the 
> cloudservice's load-balancer which has a single public IP address -- as 
> you also mention. It appears that the ssh_port and winrm_port values 
> are basically port forwards (known as "InputEndpoints"[2] in Azure 
> parlance) set on the load-balancer. These port forwards allow access 
> to the individual VMs within the cloudservice. On the VMs themselves 
> the sshd service is still expected to be listening on port 22 [3]. 
> 
> So ssh_port and winrm_port (and possibly 
> other?) InputEndpoints are truly managed by the Azure cloud. While the 
> naming might stand some improving (i.e. 
> node['azure']['input_endpoints']['ssh']['port']) they 
> most definitely are legit and (in most cases) necessary for the azure 
> cloud plugin. 
> 
> Sorry for the long preamble, but I thought it might help give other 
> chef-devs some context. 
> 
> Two questions: 
> 
> 1) Is it possible to patch "knife ssh" with some azure specific logic 
> to check if a node['azure']['ssh_port] key is defined and use it's 
> value over Chef::Config[:knife][:ssh_port] || ssh_config[:port]? 
> 
> 2) Are there any other clouds that currently managing port forwards in 
> a similar way? 
> 
> If the answer to #2 is yes, then +1 for adding it to the cloud plugin 
> interface in a cloud agnostic way. If not, IMHO, we should wait for a 
> second cloud to help us achieve a better abstraction in node['cloud']. 
> Until that time we should be able to simply use the node['azure'] 
> values directly. 
> 
> Your feedback is much appreciated! 
> 
> - Cary P 
> 
> 
> [1] http://msdn.microsoft.com/en-us/library/gg441304.aspx ;
> [2] http://msdn.microsoft.com/en-us/library/windowsazure/jj157186.aspx ;
> [3] 
> https://github.com/opscode/knife-azure/blob/master/lib/azure/role.rb#L269 ;
> 
> 
> On Tue, Dec 31, 2013 at 3:05 PM, Jeff Mendoza 
> <
 <mailto:
 >>
>  wrote: 
> Hi Cary, 
> I took a look at this again, and I think ssh_port should be left under 
> cloud, and not specific to azure. I would like to patch 'knife ssh' to 
> use ssh_port, much in the same way that it uses cloud.public_hostname 
> now. 
> (https://github.com/opscode/chef/blob/master/lib/chef/knife/ssh.rb#L157) 
> This can't be azure specific for obvious reasons. 
> Azure can have multiple nodes behind a single virtual IP or hostname, 
> and use different ports for ssh. I can imagine having customized ssh 
> ports per-node could be desirable in other situations. 
> Thanks, 
> Jeff Mendoza 
> 
> Date: Mon, 23 Dec 2013 15:51:42 -0800 
> From: 
> 
 <mailto:
 >
>  
> To: 
> 
 <mailto:
 >
>  
> Subject: [chef-dev] REVIEW: Ohai Cloud Plugin Improvements (OHAI-542) 
> Ohai! 
> 
> Just submitted a PR to help make the ohai cloud plugin more consistent 
> across clouds: 
> 
> https://tickets.opscode.com/browse/OHAI-542 ;
> 
> There are some breaking changes for GCE and Azure as documented. 
> 
> Thoughts? Questions? Concerns? 
> 
> Best regards, 
> Cary P 
>