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

["Scott M. Likens" < >]

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

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:

" type="cite">

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 < " target="_blank"> > 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 < "> > 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

Phone: (805) 243-0222
Email: " target="_blank">

!DSPAM:52bdbdf2107001589613508!