Feature #7559
Fact for identifying Amazon VPC instances.
| Status: | Needs Decision | Start date: | 05/17/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | library | |||
| Target version: | - | |||
| Keywords: | Affected Facter version: | |||
| Branch: | ||||
| Votes: | 2 |
Description
(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.
/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
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:
def has_euca_mac?
!!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:})
end
Related issues
History
Updated by Nigel Kersten about 1 year ago
- Affected Facter version set to 1.5.9rc6
Updated by Nick Lewis about 1 year ago
This thread on the AWS developer forums seems to indicate there are other possible MAC schemes for VPC nodes:
https://forums.aws.amazon.com/thread.jspa?threadID=62617
So MAC address doesn’t seem to be a reliable way to determine EC2-ness.
Updated by James Turnbull about 1 year ago
VPC != EC2. I’d suggest we’d create a different fact for this.
Updated by Nigel Kersten 12 months ago
- Tracker changed from Bug to Feature
- Subject changed from EC2 fact doesn't work with Amazon VPC instances to Fact for identifying Amazon VPC instances.
- Affected Facter version deleted (
1.5.9rc6)
ok. re-titled as feature request.
Updated by James Turnbull 9 months ago
- Category set to library
Updated by Ken Barber 6 months ago
- Target version set to 186
Updated by Ken Barber 3 months ago
- Status changed from Accepted to Duplicate
- Target version deleted (
186)
Duplicated and fixed by: #11196.
Updated by Michael Arnold 2 months ago
- Status changed from Duplicate to Re-opened
I am not seeing this issue as being fixed. As it stands, an EC2 instance in a VPC does not have the magic fe:ff:ff:ff:ff:ff MAC and does not match “has_euca_mac” leading to the EC2 facts not being populated. I would like to see a way for VPC instances to be identified so that the http://169.254.169.254:80/ connection will be triggered and the correct facts can be populated.
Updated by James Turnbull about 1 month ago
- Status changed from Re-opened to Needs Decision
- Assignee set to Ken Barber
Updated by Daniel Pittman about 1 month ago
It seems like we should use some more official API for this, and at least reference that documentation in the code. Ideally Amazon have some useful mechanism beyond the MAC of the adapter that will help understand what hardware this is running on.
Updated by Patrick Otto 22 days ago
+1 with dpittman, it looks like this needs a more general approach as this is also a problem on OpenStack. I’m not sure yet wether this can be fixed by defining the MAC address range (either in OpenStack or libvirt), but I’m looking into this (as I’m submitting a few fixes for bodepd’s openstack project).
A 12.04 guest on a 12.04 Essex compute host:
ubuntu@hello-world:~$ curl http://169.254.169.254/2008-02-01/meta-data/instance-id
i-00000002
ubuntu@hello-world:~$
ubuntu@hello-world:~$ facter -d metadata
Caught recursion on kernel
value for kernel is still nil
Not an EC2 host
ubuntu@hello-world:~$
Updated by Ken Barber 12 days ago
- Assignee deleted (
Ken Barber)