Puppet » Facter

What ruby version are you using?

This might be a better version of the fact – http://www.devco.net/archives/2009/11/09/rightscale_facts.php

James Turnbull wrote:

This might be a better version of the fact – http://www.devco.net/archives/2009/11/09/rightscale_facts.php

This one is rightscale specific, the existing one (which I didnt know about) should work on all ec2 machines – though not sure why it didnt for me.

Not sure which is the best approach, but not sure fetching all the meta data every time is the right one eventhough they do seem to change now and then.

FWIW talking with the ubuntu-server guys, some of the meta-data can change during the life of an instance.

Also, this totally hosed up my puppet installation until I removed the rescue filter. (It doesn’t matter -why- we didn’t get metadata. It is sufficient that we didn’t, and we should move on..)

There’s a patch for this here:

http://groups.google.com/group/puppet-dev/browse_thread/thread/ab1570b7fc9c49fd/c7fa205e641bec46

But it mentions causing a delay, which seems not to have been addressed.

Is there any way to confine the fact to EC2?

There are a few approaches you could do to limit the systems exposed to?

This suggests:

• Am I on xen
• am I on 10/8 (although not sure that works with Virtual Private Cloud)
• does an arp entry for 169.254.169.254 exist

http://developer.amazonwebservices.com/connect/message.jspa?messageID=122591

So we probably want an in_ec2 based on that and then get the meta-data facts.

Paul – how about this code:

http://bazaar.launchpad.net/~eythian/+junk/ec2facts/annotate/head:/facts/ec2facts.rb

James Turnbull wrote:

Paul – how about this code:

http://bazaar.launchpad.net/~eythian/+junk/ec2facts/annotate/head:/facts/ec2facts.rb

I think these 2 solve different problems. The original facter fact will take all the meta data and add facts for them. The code in this link will add facts from the user data and only the instanceid nothing else.

This script above works but: i had to change the URLs to not be a date specific instead ‘latest’ also the path to arp isnt always right and the IP for retrieving the information will only be in the ARP cache if there’s been a connection attempt so a fresh boot wont have it.

RI – note that I believe most AMI’s get their root ssh keys from 169.254.169.254 eg /usr/local/sbin/get-credentials.sh in the Amazon fedora images. Obviously this may not be true from custom built AMIs, but even then they probably do grab user-data in early boot.

Problem is we need to care about linux, opensolaris, windows.

Nick’s patch is the correct one. It doesn’t introduce a 2 second timeout; it enables one which was already accepted and is supposed to be happening.

Chris’s original patch does not actually fix the issue; the issue is that open-uri only monkeypatches open() to be able to recognize non-file:/// uri schemas, not to take TCPSocket.open() semantics. Eliminating the second argument (which open() sees as the mode) does not solve the problem, as it still sees “169.254.169.254” as a file name. It should be called with “http://#{ip}:#{port}/” as its only argument.

Nick Lewis wrote:

There’s a patch for this here:

http://groups.google.com/group/puppet-dev/browse_thread/thread/ab1570b7fc9c49fd/c7fa205e641bec46

But it mentions causing a delay, which seems not to have been addressed.

Technically it’s my patch.

I’ll sync/rediff, and resend for review.