Backport/facter 2/fact 185 ec2 metadata #657
Conversation
Without this patch Facter has no clear way to define the EC2 related facts in a robust and reliable manner. This is a problem because Facter needs to run as robustly on nodes that are inside of EC2 as it does on nodes that are outside of EC2. The root cause of the problem is that we have no way to introspect the system to determine if we're on EC2 or not without making a network call to the metadata server. [1] This means that either non-EC2 nodes will suffer a timeout trying to connect to a non-existent metadata server or EC2 nodes will suffer from facts not being defined. This patch addresses the problem by adding a new utility method with the following behavior. A block is accepted and will be executed only under the following conditions. The block should execute whatever code is necessary to define the EC2 facts themselves. 1: Do not execute if the virtual fact is not "xenu" 2: Do not execute the metadata server does not respond in 100ms after three consecutive attempts. [1] https://forums.aws.amazon.com/thread.jspa?threadID=62617
Without this patch the EC2 facts use a number of methods to determine if they're running on openstack, Amazon EC2, eucalyptus, and others. These methods have proved to be lacking robustness. This is a problem because Facter fails to define facts even when a Metadata server is available. This patch addresses the problem by changing the behavior of deciding when to define the dynamic EC2 facts. The Facter::Util::EC2.with_metadata_server method is used with a 50ms timeout over three consecutive retries. With this patch applied the EC2 metadata and userdata facts will be defined whenever the node is has a virtual fact value of "xenu" and there is a metadata data server available at http://169.254.169.254 This patch also removes the `userdata` and `metadata` methods that were previous defined as instance methods on the base Object class. Backport from master to facter-2 by Adrien Thebo <adrien@puppetlabs.com> Conflicts: lib/facter/util/ec2.rb spec/unit/ec2_spec.rb spec/unit/util/ec2_spec.rb
The previous implementation of the EC2 metadata facts could only produce flattened version of the EC2 metadata. Since we can now return structured facts it makes more sense to return the structure data in the original form.
|
CLA signed by all contributors. |
To maintain compatibility with the existing EC2 facts, we need to return both a structured version of the EC2 facts as well as flattened versions. This has the unfortunate side effects of forcing fact evaluation at fact load time, but between the options of managing a singleton object, duplicating the API queries, and forcing the evaluation, the last one seems the least bad.
When testing a resolution, the confines may be tested to confirm suitability on a given platform and so may be changed without destroying and recreating the resolution. Because of this we need to recalculate suitability every time #suitable? method is invoked. In normal operation fact suitability is only determined once so this should have no performance impact.
The resolution_type method is needed when reopening a fact definition
with the Facter 2.0 API:
Facter.define_fact(:myfact) do
define_resolution(:myres) do
# [...]
The aggregate resolution type implemented this but Util::Resolution did
not, which could cause errors using the new syntax. This corrects the
omission.
|
Is it possible to add something to the json schema for the ec facts? I think the answer is no, because we just turn the contents of the uri into a series of facts, so the code doesn't actually know enough to say anything about the format or names of those facts. But wanted to at least ask the question :) |
|
I think it's possible to update the schema for the structured For the flattened Before I launch into a discussion of where this is merged, I think that there are a couple of commits that should be pulled out of this and merged/released in 2.0.2. I'll pull those out into separate PRs shortly. With respect to where this gets merged, introducing the I also wanted to touch briefly on how this code is structured. This continues to perpetuate the pattern of stuffing all complex logic into Lastly, and I just realized this - we still have to commit to the old API for Thoughts? |
|
Oh awesome, thanks for the great comment. Here are some $.02:
|
|
Pull request for |
|
Closing in favor of GH-661. |
3 participants
This backports the changes in the master branch for EC2 facts and updates them to return both structured and flattened ec2 metadata facts.