Issue #11666 has been updated by Ken Barber. Status changed from In Topic Branch Pending Review to Needs Decision
I'm gonna change this to 'Needs Decision' for now - I think the need is defined, just the implementation needs a decision. > Does this conflate with the virtual facts anyway? Hmmm perhaps not. Not really - but its close. Having said that - the direction of the virtual flag is a funny one. You could have a 'is_cloud?' type of thing ... > I am concerned it will have the same problem as the `virtual` fact: that you > could, eg, be a euca node, and a host for a container stack, or something > like that. Specifically, that this is a *set* of booleans, not a single > value, where one string ends up packing it down in ways that it shouldn't. This is fair enough. You could always provide an array of containers though - comma separated. So yes - there is a slim chance but you could have an Openstack node running using just QEMU on an EC2 instance. What is the right answer then I wonder? And since the use-case is primarily the the EC2 API - does it still have meaning to the embedded node in that case? If you could somehow emulate the API in such a case it would still work regardless. In the cases where say it was Openstack inside Linode you would only need to openstack knowledge to judge weither an API call is needed. I'm just going to shove down some random notes - sorry - just thinking about this issue a bit lately (see #11566). I believe ultimately to solve the issue James has had - we only really want to worry about: EC2, OpenStack (we don't support this yet - but there is a ticket for it) and Eucalyptus ... and then any other platform that comes along and supports the API. But stepping back and thinking about 'cloud identification' what are the possibilities here? Privates: * Openstack * Eucalyptus * OpenNebula * VMWare VCloud (how does one distinguish this from just a vmware box I wonder?) Publics: * EC2 (this actually has the same problem as VCloud but for Xen but we work around it horribly with a timeout) * Rackspace * Linode * ... others Implementation aside ... what other use-cases are there for this kind of thing? * In Opennebula the metadata is not via an emulated API - its via a local ISO mount ... so knowing that its specifically opennebula would be useful. * At Linode you have this guy: http://blog.linode.com/2009/08/03/linode-api-2-0/ which might be useful to know about (not sure if it provides information that a node would be safe to hit though) Two negative points on trying to do this properly: * I think identifying a cloud type is really really hard in a lot of cases since they are mainly just sitting on another virt platform (and we all know its hard enough just to figure that thing out). OpenNebula & OpenStack at least both nab mac address prefixes which is much much easier (but I notice they aren't reserving them with the IETF I believe). * Also - what quantifies a 'cloud' anyway? Look at the VCloud example. The only differentiator is the way VM's are launched. Trying to do it properly could turn into the virtual fact debacle - without good techniques people will just consider the thing buggy. Since the logic in virtual is to assume 'physical' if none of the general forensics match - users assume we are doing something amazing to come to that conclusion. I think falling back to nil (ie. no fact) will set the expectation properly as this is our defacto 'unknown' return (maybe we should consider this for the virtual fact :-). Now that I think about it - this actually puts weight on a single fact (list or singular) as apposed to a set of booleans. Thoughts? ---------------------------------------- Feature #11666: Add is_ec2 and is_euca facts https://projects.puppetlabs.com/issues/11666 Author: James Turnbull Status: Needs Decision Priority: Normal Assignee: Category: library Target version: 1.7.x Keywords: Branch: https://github.com/puppetlabs/facter/pull/138 Affected Facter version: Sometimes you just want to know if a host is EC2 or Eucalyptus. This adds two facts in a similar vein to "is_virtual". -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
