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.
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
- 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:
> Just submitted a PR to help make the ohai cloud plugin more consistent across clouds:
> There are some breaking changes for GCE and Azure as documented.
> Thoughts? Questions? Concerns?
> Best regards,
> Cary P
Archive powered by MHonArc 2.6.16.