REVIEW: Ohai Cloud Plugin Improvements (OHAI-542)


#1

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


#2

We have a need for much better info from the rackspace plugin in the near future. Notable things we’re wanting:

  • instance id
  • instance size/flavor
  • base image
  • metadata
  • attached volumes

Is it worth shooting for this across IaaS providers, and ultimately getting into node[‘cloud’]?

On 2013-12-23, at 23:51, Cary Penniman cary@rightscale.com wrote:

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


#3

Joseph,

Thank you for the reply.

The meanings behind instance-id, instance-size and metadata are fairly
specific to a given IaaS orchestration layer (aka "cloud). For example,
how does an “1GB Standard” Rackspace instance compare to a “m1-small” EC2
instance? Typically using these values in a meaningful way will require
cloud specific logic – at which point, one might as well use the
cloud-specific node[‘rackspace’] or node[‘ec2’] plugin values directly.

The idea behind the “cloud” plugin (ironically?) is to provide
cloud-agnostic details about the VM (like ip address and hostname) in a
constant location in order to avoid adding logic that switches on
node[‘cloud’][‘provider’]. Of course if you are writing more advanced
recipes, like creating cloud volumes, you will likely need cloud specific
stuff in your recipes. But for simple things like setting up a public LAMP
server you shouldn’t.

The proposal below is an attempt to define the node[‘cloud’] key
"interface" in a more rigorous way, to avoid the cloud-specific "key-creep"
that has occurred over time. This interface can absolutely be extended to
provide other keys that are generic but provided/managed by a cloud
orchestration layer.

In fact, reporting a list of attached volumes (e.g. [’/dev/xvde’,
’/dev/xvdf’]) is an interesting idea. I think something similar for
ephemeral devices might also make sense. The other items you mentioned I
suggest we add to the rackspace plugin.

Best regards,

Cary P

On Mon, Dec 23, 2013 at 5:52 PM, Joseph Holsten joseph@josephholsten.comwrote:

We have a need for much better info from the rackspace plugin in the near
future. Notable things we’re wanting:

  • instance id
  • instance size/flavor
  • base image
  • metadata
  • attached volumes

Is it worth shooting for this across IaaS providers, and ultimately
getting into node[‘cloud’]?

On 2013-12-23, at 23:51, Cary Penniman cary@rightscale.com wrote:

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


Cary Penniman
Systems Architect
www.RightScale.com http://www.rightscale.com/

Phone: (805) 243-0222
Email: cary@rightscale.com


#4

Hi,

I know my 2cents are likely only worth 1 hay penny. But here goes.

Overloading node[‘cloud’] with virtually all the keys possible from
node[‘ec2’] or node[‘rackspace’] could go either way in several regards.

  • Instead of having nested loops of if node.has_key?(‘ec2’) # for
    example with following if’s for rackspace … …
  • Make 1 central key base for all ‘cloud based’ keys. This is likely
    a pro, not a con but your perspective may change this opinion.

If we cloned the objects from node[‘ec2’] into node[‘cloud’] memory
allocation should not be affected much; which means we would not do away
with node[‘ec2’] it would just have it’s attributes cloned into
node[‘cloud’].

I have never used the instance size for anything meaningful in chef;
instead I typically use node[‘cpu’] (like node.cpu.total). Maybe I just
haven’t had the opportunity :slight_smile:

I imagine this is something good to have on the Radar making chef DRY
(as well as useable) is always a win.

Scott

On 12/27/13, 9:50 AM, Cary Penniman wrote:

Joseph,

Thank you for the reply.

The meanings behind instance-id, instance-size and metadata are fairly
specific to a given IaaS orchestration layer (aka “cloud). For
example, how does an “1GB Standard” Rackspace instance compare to a
"m1-small” EC2 instance? Typically using these values in a meaningful
way will require cloud specific logic – at which point, one might as
well use the cloud-specific node[‘rackspace’] or node[‘ec2’] plugin
values directly.

The idea behind the “cloud” plugin (ironically?) is to provide
cloud-agnostic details about the VM (like ip address and hostname) in
a constant location in order to avoid adding logic that switches on
node[‘cloud’][‘provider’]. Of course if you are writing more advanced
recipes, like creating cloud volumes, you will likely need cloud
specific stuff in your recipes. But for simple things like setting up
a public LAMP server you shouldn’t.

The proposal below is an attempt to define the node[‘cloud’] key
"interface" in a more rigorous way, to avoid the cloud-specific
"key-creep" that has occurred over time. This interface can
absolutely be extended to provide other keys that are generic but
provided/managed by a cloud orchestration layer.

In fact, reporting a list of attached volumes (e.g. [’/dev/xvde’,
’/dev/xvdf’]) is an interesting idea. I think something similar for
ephemeral devices might also make sense. The other items you
mentioned I suggest we add to the rackspace plugin.

Best regards,

Cary P

On Mon, Dec 23, 2013 at 5:52 PM, Joseph Holsten
<joseph@josephholsten.com mailto:joseph@josephholsten.com> wrote:

We have a need for much better info from the rackspace plugin in
the near future. Notable things we're wanting:
- instance id
- instance size/flavor
- base image
- metadata
- attached volumes

Is it worth shooting for this across IaaS providers, and
ultimately getting into node['cloud']?

On 2013-12-23, at 23:51, Cary Penniman <cary@rightscale.com
<mailto:cary@rightscale.com>> wrote:

> 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
>


Cary Penniman
Systems Architect
www.RightScale.com http://www.rightscale.com/

Phone: (805) 243-0222
Email: cary@rightscale.com mailto:cary@rightscale.com

!DSPAM:52bdbdf2107001589613508!


#5

The cloud specific Mash structure (i.e. node[‘ec2’]) can drastically vary
from cloud to cloud. Both ec2 and gce plugins follow their metadata tree
structure – which, IMHO, is a good thing.

The problem I see with cloning the structure from the cloud specific Mash
to node[‘cloud’], is that the keys will differ depending on which cloud you
are running. For example, getting the ip address running on EC2 would be:

node[:cloud][:public_ipv4]

whereas on GCE it would be something like:

node[‘cloud’][‘network’][‘networkInterface’][0][‘accessConfiguration’][0][‘externalIp’]

In this case, you would still need to add conditional logic like “if
node.has_key?(‘ec2’)”, but now the recipe is harder to understand unless
you know about the magic cloning that the cloud plugin does. Even if we
wanted all the cloud plugins to produce the exact same Mash structure (or
some subset), it would be difficult to enforce across all plugins when
reviewing a simple Pull Request because the code would reside in multiple,
seemingly unrelated files.

The cloud plugin today already creates a common Mash structure (or some
subset) that is reviewable in a single file, but since it is an
unstructured Hash it is very easy to miss subtle differences. The
pull-request I have submitted uses a simple ruby object to help enforce the
structure of the cloud Mash. It does so by taking responsibility for
writing the Mash itself. By insuring a consistent interface, we should
avoid the need to use of conditional logic like "if node.has_key?(‘ec2’)"
and the like.

Hopefully some of that makes sense.

Cheers!

On Fri, Dec 27, 2013 at 10:51 AM, Scott M. Likens scott@likens.us wrote:

Hi,

I know my 2cents are likely only worth 1 hay penny. But here goes.

Overloading node[‘cloud’] with virtually all the keys possible from
node[‘ec2’] or node[‘rackspace’] could go either way in several regards.

  • Instead of having nested loops of if node.has_key?(‘ec2’) # for
    example with following if’s for rackspace … …
  • Make 1 central key base for all ‘cloud based’ keys. This is likely
    a pro, not a con but your perspective may change this opinion.

If we cloned the objects from node[‘ec2’] into node[‘cloud’] memory
allocation should not be affected much; which means we would not do away
with node[‘ec2’] it would just have it’s attributes cloned into
node[‘cloud’].

I have never used the instance size for anything meaningful in chef;
instead I typically use node[‘cpu’] (like node.cpu.total). Maybe I just
haven’t had the opportunity :slight_smile:

I imagine this is something good to have on the Radar making chef DRY(as well as useable) is always a win.

Scott

On 12/27/13, 9:50 AM, Cary Penniman wrote:

Joseph,

Thank you for the reply.

The meanings behind instance-id, instance-size and metadata are fairly
specific to a given IaaS orchestration layer (aka "cloud). For example,
how does an “1GB Standard” Rackspace instance compare to a “m1-small” EC2
instance? Typically using these values in a meaningful way will require
cloud specific logic – at which point, one might as well use the
cloud-specific node[‘rackspace’] or node[‘ec2’] plugin values directly.

The idea behind the “cloud” plugin (ironically?) is to provide
cloud-agnostic details about the VM (like ip address and hostname) in a
constant location in order to avoid adding logic that switches on
node[‘cloud’][‘provider’]. Of course if you are writing more advanced
recipes, like creating cloud volumes, you will likely need cloud specific
stuff in your recipes. But for simple things like setting up a public LAMP
server you shouldn’t.

The proposal below is an attempt to define the node[‘cloud’] key
"interface" in a more rigorous way, to avoid the cloud-specific "key-creep"
that has occurred over time. This interface can absolutely be extended to
provide other keys that are generic but provided/managed by a cloud
orchestration layer.

In fact, reporting a list of attached volumes (e.g. [’/dev/xvde’,
’/dev/xvdf’]) is an interesting idea. I think something similar for
ephemeral devices might also make sense. The other items you mentioned I
suggest we add to the rackspace plugin.

Best regards,

Cary P

On Mon, Dec 23, 2013 at 5:52 PM, Joseph Holsten joseph@josephholsten.comwrote:

We have a need for much better info from the rackspace plugin in the near
future. Notable things we’re wanting:

  • instance id
  • instance size/flavor
  • base image
  • metadata
  • attached volumes

Is it worth shooting for this across IaaS providers, and ultimately
getting into node[‘cloud’]?

On 2013-12-23, at 23:51, Cary Penniman cary@rightscale.com wrote:

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


#6

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: cary@rightscale.com
To: chef-dev@lists.opscode.com
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


#7

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 jeffmendoza@live.com 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: cary@rightscale.com
To: chef-dev@lists.opscode.com
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


#8

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: cary@rightscale.com
To: jeffmendoza@live.com
CC: chef-dev@lists.opscode.com

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
<jeffmendoza@live.commailto:jeffmendoza@live.com> 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: cary@rightscale.commailto:cary@rightscale.com
To: chef-dev@lists.opscode.commailto:chef-dev@lists.opscode.com
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


#9

Hi All,

I went ahead with node[‘azure’][‘public_ssh_port’] for the PR: https://tickets.opscode.com/browse/CHEF-4962
This can be changed to node[‘cloud’][‘ssh_port’] if ssh_port is added to cloud.

Thanks,
Jeff


From: jeffmendoza@live.com
To: cary@rightscale.com
CC: chef-dev@lists.opscode.com
Date: Fri, 10 Jan 2014 15:16:35 -0800
Subject: [chef-dev] RE: REVIEW: Ohai Cloud Plugin Improvements (OHAI-542)

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: cary@rightscale.com
To: jeffmendoza@live.com
CC: chef-dev@lists.opscode.com

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
<jeffmendoza@live.commailto:jeffmendoza@live.com> 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: cary@rightscale.commailto:cary@rightscale.com
To: chef-dev@lists.opscode.commailto:chef-dev@lists.opscode.com
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


#10

+1

On Wed, Jan 15, 2014 at 1:59 PM, Jeff Mendoza jeffmendoza@live.com wrote:

Hi All,

I went ahead with node[‘azure’][‘public_ssh_port’] for the PR:
https://tickets.opscode.com/browse/CHEF-4962
This can be changed to node[‘cloud’][‘ssh_port’] if ssh_port is added to
cloud.

Thanks,
Jeff


From: jeffmendoza@live.com
To: cary@rightscale.com
CC: chef-dev@lists.opscode.com
Date: Fri, 10 Jan 2014 15:16:35 -0800
Subject: [chef-dev] RE: REVIEW: Ohai Cloud Plugin Improvements (OHAI-542)

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: cary@rightscale.com
To: jeffmendoza@live.com
CC: chef-dev@lists.opscode.com

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
<jeffmendoza@live.commailto:jeffmendoza@live.com> 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: cary@rightscale.commailto:cary@rightscale.com
To: chef-dev@lists.opscode.commailto:chef-dev@lists.opscode.com
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


Cary Penniman
Systems Architect
www.RightScale.com http://www.rightscale.com/

Phone: (805) 243-0222
Email: cary@rightscale.com
Skype: carypenniman