Issue #7559 has been updated by Jeff McCune.
Michael Arnold wrote: > Dara Adib wrote: > > <cite>Why don’t we just solve this problem the simple way and query for the > > availability of the service endpoint?</cite> > > > > James mentioned in an earlier comment that doing so would introduce a delay > > for non-EC2 users until facter times out. True, the timeout limit could be > > reduced, but I'm guessing that's not really ideal. > > I am not clear on why a delay would be more of an impact than broken facts. > Getting the correct facts is of greater importance to me than how long it > takes to run facter. Querying for the availability of the endpoint is (much) more of an impact because it would affect every user, regardless of if they run in EC2 or not, every time facts are resolved. As it stands now, the EC2 user data facts are broken, yes, but this impacts a subset of users; those running in EC2. The next steps are to come up with a fact that we can confine the userdata facts against. The fact may very well just be a "hint" that comes from a file in the filesystem, in which case the external facts functionality should be used. Lastly, I really encourage everyone who is affected by this issue to push Amazon to provide a way to introspect in a fast, reliable, and non-blocking way if the instance is running in EC2 or not. If you do ping Amazon about this, you might reference this information from Google Compute Engine: [Detecting if You Are Running in Google Compute Engine](https://developers.google.com/compute/docs/instances#dmi). This functionality is important because we need a way to develop applications that work well both inside and outside of the EC2 environment. Hope this helps, -Jeff ---------------------------------------- Feature #7559: Fact for identifying Amazon VPC instances. https://projects.puppetlabs.com/issues/7559#change-78284 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.
