Issue #7559 has been updated by Evan Stachowiak.
Support Urls deleted (https://support.puppetlabs.com/tickets/840)
This looks like it is related to this virt-what bug:
https://bugzilla.redhat.com/show_bug.cgi?id=973663
If you uninstall virt-what to fix, be careful because the RPM spec in
Issue #7559 has been updated by Rafael Correa.
Support Urls deleted (https://support.puppetlabs.com/tickets/840)
I had the same issue Jonathan.
The problem happens when facter defaults the value of the virtual fact to the
output of virt-what. It says xen instead of xenu, which breaks the
Issue #7559 has been updated by Charlie Sharpsteen.
Keywords changed from vpc ec2 arp to vpc ec2 arp customer
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559#change-88643
* Author: Nigel Kersten
*
Issue #7559 has been updated by Thomas Vachon.
Support Urls deleted (https://support.puppetlabs.com/tickets/840)
So it looks like this doesn't work in Openstack. However, 1.6.14 did show ec2
facts.
precode
facterversion = 2.0.0-rc4
...
lib = ./facter
...
lsbdistdescription = Ubuntu 12.04.1
Issue #7559 has been updated by Thomas Vachon.
Support Urls deleted (https://support.puppetlabs.com/tickets/840)
Jeff,
You can tag openstack testing to me. I'll run it through tomorrow on Folsom for
you. Not sure if you want to assign to me for testing or just leave this
comment as my ill
Issue #7559 has been updated by Thomas Vachon.
Support Urls deleted (https://support.puppetlabs.com/tickets/840)
Jeff,
You can tag openstack testing to me. I'll run it through tomorrow on Folsom for
you. Not sure if you want to assign to me for testing or just leave this
comment as my ill
Issue #7559 has been updated by Jonathan Sabo.
I've been trying to get the ec2 facts to work in VPC on Redhat's AMI:
RHEL-6.3-Starter-x86_64-1-Hourly2 (ami-cc5af9a5) and even with the latest code
it's not working and I think it's because facter virtual reports xen and not
xenu. Is this
Issue #7559 has been updated by Jeff McCune.
On Sunday, February 3, 2013, wrote:
Issue #7559 has been updated by Jonathan Sabo.
I’ve been trying to get the ec2 facts to work in VPC on Redhat’s AMI:
RHEL-6.3-Starter-x86_64-1-Hourly2 (ami-cc5af9a5) and even with the latest
code it’s not
Issue #7559 has been updated by Jeff McCune.
Unfortunately I still need validation of this on OpenStack. Apparently the
next gen RackSpace cloud is based on OpenStack, but they're removed support
for the metadata server at http://169.254.169.254 [1]. In the RackSpace
next-generation cloud,
Issue #7559 has been updated by Justin Lambert.
Using facter 1.6.17 (puppetlabs RPM) on CentOS 6.3 in a VPC the virtual fact
returned is 'xen' rather than 'xenu' for me.
$ sudo virt-what
xen
virt-what version 1.11-1.1
Feature #7559: Fact for
Issue #7559 has been updated by Jeff McCune.
Justin Lambert wrote:
Using facter 1.6.17 (puppetlabs RPM) on CentOS 6.3 in a VPC the virtual fact
returned is 'xen' rather than 'xenu' for me.
$ sudo virt-what
xen
virt-what version 1.11-1.1
Justin, could you try the branch referenced in
Issue #7559 has been updated by Jeff McCune.
Josh Cooper wrote:
From https://projects.puppetlabs.com/issues/15391#note-3, Amazon suggests
checking for the `ec2config` service, at least on Windows.
Just as an update to this, there is no ec2config service in Amazon's own Amazon
Linux AMI.
Issue #7559 has been updated by Jeff McCune.
Assignee set to Martijn Heemels
This doesn't seem to be an issue in recent releases of Facter. I posted
similar information in #14366 but I'll cross-post it here to get as much
feedback as possible.
Martijn, if you could easily configure your
puppet || hub clone puppetlabs/puppet
test -d hiera || hub clone puppetlabs/hiera
(cd facter; bundle install --path vendor)
echo All done! Vim and your shell are setup, log back in and cd src/facter;
bundle exec facter
/pre
Feature #7559: Fact
which has been open for 9 months. I'm seeing this behaviour on
all my EC2 and VPC instances. They all report as physical with the latest
facter available on Ubuntu 12.04 LTS (facter 1.6.5).
Feature #7559: Fact for identifying Amazon VPC instances.
https
Issue #7559 has been updated by Jeff McCune.
Thanks Martijn,
I'll have a look at both this ticket and the related one on Tuesday. Sorry
this has been affecting you.
-Jeff
Feature #7559: Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Brian Wong.
Jeff McCune wrote:
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.
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
Issue #7559 has been updated by Justin Lambert.
Jeff McCune wrote:
Brian Wong wrote:
Jeff McCune wrote:
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
Issue #7559 has been updated by Brian Wong.
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
Issue #7559 has been updated by Michael Arnold.
Jeff McCune wrote:
Michael Arnold wrote:
Does item 3 break on openstack or eucalyptus?
It might. Could you capture a copy of the metadata headers and let me know
what they look like on those two platforms?
Sorry, I was being
Issue #7559 has been updated by Jeff McCune.
Michael Arnold wrote:
Jeff McCune wrote:
Thoughts?
Does item 3 break on openstack or eucalyptus?
It might. Could you capture a copy of the metadata headers and let me know
what they look like on those two platforms?
Otherwise, outside of
Issue #7559 has been updated by Josh Cooper.
Ryan Coleman wrote:
Would it help to make this fact a module that is distributed through the
Puppet Forge instead of making a part of core Facter? Those running in EC2
can install the module and pluginsync the fact to their agents.
It would for
Issue #7559 has been updated by Justin Lambert.
Ryan Coleman wrote:
Would it help to make this fact a module that is distributed through the
Puppet Forge instead of making a part of core Facter? Those running in EC2
can install the module and pluginsync the fact to their agents.
It would
Issue #7559 has been updated by Ryan Coleman.
Josh Cooper wrote:
Ryan Coleman wrote:
Would it help to make this fact a module that is distributed through the
Puppet Forge instead of making a part of core Facter? Those running in EC2
can install the module and pluginsync the fact to
Issue #7559 has been updated by Ryan Coleman.
Justin Lambert wrote:
Ryan Coleman wrote:
Would it help to make this fact a module that is distributed through the
Puppet Forge instead of making a part of core Facter? Those running in EC2
can install the module and pluginsync the fact to
Issue #7559 has been updated by Jeff McCune.
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
Issue #7559 has been updated by James Turnbull.
Looks good. Will 3. be faster than can_connect?
Thanks Jeff!
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559#change-78412
Author: Nigel Kersten
Issue #7559 has been updated by Michael Arnold.
Jeff McCune wrote:
Thoughts?
Does item 3 break on openstack or eucalyptus?
Otherwise, outside of any issues with the timeout, I think this is an
acceptable solution.
Feature #7559: Fact for identifying
Issue #7559 has been updated by Michael Arnold.
Why don't we just solve this problem the simple way and query for the
availability of the service endpoint? Replace this:
if (Facter::Util::EC2.has_euca_mac? || Facter::Util::EC2.has_openstack_mac?
||
Facter::Util::EC2.has_ec2_arp?
Issue #7559 has been updated by Dara Adib.
citeWhy 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
.
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559#change-78256
Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee:
Category: library
Target version:
Keywords: vpc ec2 arp
Branch:
Affected Facter version: 1.6.10
Issue #7559 has been updated by C Lang.
Well said, Michael.
Amazon implied we could rely on a very fast response from the local meta data
service, so if this is a huge concern, it seems like we could set a shorter
timeout to reduce the impact on other systems.
If we can't, I'd think we'd
Issue #7559 has been updated by Jeff McCune.
Michael Arnold wrote:
Dara Adib wrote:
citeWhy 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
Issue #7559 has been updated by Jeff McCune.
One other idea;
What if there was a configuration setting in Facter that allowed you to enable
the facts that require the metadata server? This setting would default to
being turned off so users outside of EC2 aren't affected by an unresponsive
Issue #7559 has been updated by Josh Cooper.
Others wanting to determine EC2-ness without making network calls:
https://forums.aws.amazon.com/message.jspa?messageID=122425br
https://code.launchpad.net/~eythian/+junk/ec2factsbr
https://forums.aws.amazon.com/message.jspa?messageID=54868br
Seems
Issue #7559 has been updated by Jeff McCune.
James Turnbull wrote:
As far as I can see we've investigated all the other approaches with
customers and AWS (much of that is in this ticket - thanks to C Lang and
others) and have not been able to find resolution. At this stage I'd say
we're
Issue #7559 has been updated by James Turnbull.
It doesn't require installing Puppet and the stdlib module on a host. A lot of
our customers rely on Facter knowing it is AWS or a VPC during provisioning
before Puppet is to be deployed or they use the facts generated. Razor is
another
Issue #7559 has been updated by James Turnbull.
This doesn't resolve the check issue though - having facter_dot_d allows us to
specify a fact identifying the type of system but the EC2 fact won't check for
this information. Or am I missing something?
Issue #7559 has been updated by C Lang.
I went a few rounds with them and ended up with nothing stellar. Some
non-workable ideas about public IP addresses, some highly distro specific
checks, etc.
They did confirm the metadata service is provided by the underlying hardware
of an instance,
Issue #7559 has been updated by C Lang.
MACs are completely inconsistent in a VPC. I think we can officially abandon
that suggestion.
I note that ec2 facts work fine in facter 1.6.7-1.16 in the epel repository.
That version of ec2.rb doesn't appear to check for a MAC, but just tries to
Issue #7559 has been updated by Justin Lambert.
My first three octects are 06:A2:16 on all of my VPC machines (single VPC).
Doesn't look like there is MAC consistency between VPCs.
Feature #7559: Fact for identifying Amazon VPC instances.
Issue #7559 has been updated by Justin Lambert.
I have solved this for me by updating line 28 in ec2.rb to:
Facter::Util::EC2.has_ec2_arp?) || Facter::Util::EC2.can_connect?
This could be simplified by removing all of the conditionals other than the
EC2.can_connect? check since to keep the
Issue #7559 has been updated by Ken Barber.
Assignee deleted (Ken Barber)
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559#change-62547
Author: Nigel Kersten
Status: Needs Decision
Priority: Normal
Issue #7559 has been updated by Patrick Otto.
+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
Issue #7559 has been updated by Daniel Pittman.
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
Issue #7559 has been updated by Ken Barber.
Target version set to 1.7.x
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559
Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee:
Category:
Issue #7559 has been updated by James Turnbull.
Category set to library
Feature #7559: Fact for identifying Amazon VPC instances.
https://projects.puppetlabs.com/issues/7559
Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee:
Category:
Issue #7559 has been updated by Nigel Kersten.
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.
49 matches
Mail list logo
