Issue #7559 has been updated by Jeff McCune.
Brian Wong wrote: > Jeff McCune wrote: > > The course we plan to pursue is: > > > > 1. Confine the metadata API availability check to `virtual => xenu` in > > an effort to limit this network call to a subset of Facter users. > > 2. Confine the metadata API check to a x millisecond timeout. Amazon > > says the metadata server responds quickly so let's take their word for > > it. We'll compute x by sampling these response times on some EC2 > > instances in various regions. If x turns out to be > 20ms then we're > > probably not going to take this approach. because it would negatively > > impact everyone running Facter on Xen hypervisors. > > 3. Check to see if http://169.254.169.254/latest/meta-data/ responds > > with a header of "Server: EC2ws" > > 4. If so, define a fact indicating we're inside of EC2. > > 5. Confine all of the meta-data and user-data facts to the fact set in 4. > > > > Baring any major objections I'll implement this "soon." Thoughts? > > > > -Jeff > > I just wanted to mention that my instances in VPC have `virtual => physical`. > Therefore I do not believe it is an appropriate method to limit the scope of > systems of which the network call to http://169.254.169.254 is made. This information changes the plan... We can't make this blocking I/O call over the network when facter runs on a physical host. There's just too big of an impact. I'm curious why your instance isn't reporting physical => xen. Could you let me know what Facter version you're running Brian? -Jeff ---------------------------------------- Feature #7559: Fact for identifying Amazon VPC instances. https://projects.puppetlabs.com/issues/7559#change-79684 Author: Nigel Kersten Status: Accepted Priority: Normal Assignee: Category: library Target version: Keywords: vpc ec2 arp Branch: Affected Facter version: 1.6.10 (From the list) I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS instances it works great. In VPC instances if doesn't work. This seems to be because VPC instances don't use the fe:ff:ff:... MAC addresses. <pre> /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30 inet addr:172.17.129.24 ... /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16 inet addr:172.17.128.126 /sbin/arp Address HWtype HWaddress Flags Mask Iface 169.254.169.253 ether 02:67:4E:C0:00:01 C eth0 172.17.128.1 ether 02:67:4E:C0:00:01 C eth0 </pre> Of the two VPC EC2 instances I've seen, the MAC address always start with 02:67:4E. I have only seen two instances, both in the same VPC, so I don't know if this holds for every VPC instance, YMMV. in ec2.rb , the following seemed to work: <pre> def has_euca_mac? !!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:}) end </pre> -- 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.
