Facter 3.0 breaks custom facts and dropped a needed core fact

[Ken Bowley]

While testing puppet 4 to see if it was ready for production (still not), I now get to deal with the new Facter 3.0.

Hopefully ruby based facter won't be totally abandoned, since the C++ based version is going to be an annoyance on non-PL supported systems.

The first thing I noticed is that a couple of our custom facts no longer work because they used facter utils (Facter::Util::IP, Facter::Util::Resolution).

Upon finally looking at the release info, I see that xendomains was not ported into Facter 3.0, and this fact is used all the time in our environment!  I will most likely end out reinventing the deprecated wheel of xendomains, but this just adds to the frustration that is the Puppet 4 CF.

[Peter Huene]

Hi Ken!

On Thu, Jun 25, 2015 at 11:53 AM, Ken Bowley <kbo...@gmail.com> wrote:

While testing puppet 4 to see if it was ready for production (still not), I now get to deal with the new Facter 3.0.

Hopefully ruby based facter won't be totally abandoned, since the C++ based version is going to be an annoyance on non-PL supported systems.

The first thing I noticed is that a couple of our custom facts no longer work because they used facter utils (Facter::Util::IP, Facter::Util::Resolution).

Could you elaborate on what you need from Facter::Util::IP and Facter::Util::Resolution? We did implement Facter::Util::Resolution::exec and Facter::Util::Resolution::which (despite both being marked deprecated in 2.x) as they were commonly used.  While we tried to maximize the support for any method marked "@api public", we obviously can't expose everything that existed in Facter 2.x via C++.  Facter 3 doesn't use the Ruby API internally at all; it only exists to support custom facts, so types like Facter::Util::IP didn't make much sense to me reimplement in C++ at the time.  It sounds like my understanding of that was wrong, though, so let's see what we can do to enable your custom facts.

 

Upon finally looking at the release info, I see that xendomains was not ported into Facter 3.0, and this fact is used all the time in our environment!  I will most likely end out reinventing the deprecated wheel of xendomains, but this just adds to the frustration that is the Puppet 4 CF.

The xendomains fact will be reimplemented in a Facter 3 release.  It looks like we have an existing ticket (FACT-867) for this that flew under the radar because it was not associated with the 3.0.0 release.  I'll update the ticket so that we properly track this.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ad894c61-9d36-428e-a26a-7afb6ec065fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Join us at PuppetConf 2015, October 5-9 in Portland, OR - www.2015.puppetconf.com 

Register early to save 40%!

[Ken Bowley]

Hi Peter!

On Thursday, June 25, 2015 at 9:45:51 PM UTC-7, Peter Huene wrote:

Hi Ken!

On Thu, Jun 25, 2015 at 11:53 AM, Ken Bowley <kbo...@gmail.com> wrote:

While testing puppet 4 to see if it was ready for production (still not), I now get to deal with the new Facter 3.0.

Hopefully ruby based facter won't be totally abandoned, since the C++ based version is going to be an annoyance on non-PL supported systems.

The first thing I noticed is that a couple of our custom facts no longer work because they used facter utils (Facter::Util::IP, Facter::Util::Resolution).

Could you elaborate on what you need from Facter::Util::IP and Facter::Util::Resolution? We did implement Facter::Util::Resolution::exec and Facter::Util::Resolution::which (despite both being marked deprecated in 2.x) as they were commonly used.  While we tried to maximize the support for any method marked "@api public", we obviously can't expose everything that existed in Facter 2.x via C++.  Facter 3 doesn't use the Ruby API internally at all; it only exists to support custom facts, so types like Facter::Util::IP didn't make much sense to me reimplement in C++ at the time.  It sounds like my understanding of that was wrong, though, so let's see what we can do to enable your custom facts. 

 

I don't really need Facter::Util::Resolution, backticks would work just as well, I just copied some of the xendomains code when I was tossing together a fact to grab domains with virsh for our hosts using kvm.  As for the Facter::Util::IP, that is for some custom facts that look at interfaces and determine if something is on our research network.  Basically we were avoiding re-coding what had already been done.  We used Facter::Util::IP.get_interfaces and Facter::Util::IP.get_interface_value

Upon finally looking at the release info, I see that xendomains was not ported into Facter 3.0, and this fact is used all the time in our environment!  I will most likely end out reinventing the deprecated wheel of xendomains, but this just adds to the frustration that is the Puppet 4 CF.

The xendomains fact will be reimplemented in a Facter 3 release.  It looks like we have an existing ticket (FACT-867) for this that flew under the radar because it was not associated with the 3.0.0 release.  I'll update the ticket so that we properly track this.

Good to hear!  We don't use the facts in any of the manifests, but it makes it easy to query puppetdb when we are trying to remember which host is running a specific vm.