Hello, Regarding, https://github.com/puppetlabs/facter/pull/387
One of the long standing tickets with a lot of watchers is #7559 [1] where the ec2_* metadata and userdata facts are not populated on Amazon EC2 VPC instances. This bug has been quite problematic to solve once and for all because it's difficult to know if it's OK or not OK to make HTTP requests of a server that may or may not respond. I think I have a robust solution to this problem, but it relies on the virtual fact returning a value of "xenu." If the virtual fact has a value of "xenu" then Facter will try and speak to the metadata server at http://169.254.169.254 This server will respond in many common cloud infrastructures, but will time out on a standard XenU instance. To address the timeout issue, I've simply limited the maximum time the request can take to 50ms. The implementation retries only 3 times for a maximum delay of 150ms. This approach should reliably detect the metadata server while mitigating the blocking I/O calls for environments where there is no metadata server. I've removed all infrastructure specific logic from Facter in this patch, which is where I need your help. The facts are working well for me in both an Amazon EC2 VPC and non-vpc instance, but I don't have an easy way to make sure they're working on OpenStack and Eucalyptus. I also don't have a way to ensure the 150ms delay is barely noticeable for XenU instances that do not have a metadata server. Finally, I'd like to solicit feedback on renaming all of these facts. They're no longer specific to EC2, instead they're generalized to any infrastructure that has a responsive metadata server. As a result, I'd like to rename them to have a "metadata_*" prefix instead of an "ec2_*" prefix. My idea is to provide a Puppet module or Ruby Gem that provides backwards compatibility for those people who don't want to refactor their manifests to use the new Fact names. Thoughts? Comments? Does the code in the branch work for you? [1] http://projects.puppetlabs.com/issues/7559 Thanks, -Jeff -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
