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.
On 12/27/13, 9:50 AM, Cary Penniman wrote:
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.
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
- 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 < " target="_blank"> > 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.