Add setting to use custom Facter implementation #16
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GabrielNagy
force-pushed
the
facter-impl
branch
2 times, most recently
from
5963b7d
to
e31be81
Compare
ekohl
reviewed
Nov 4, 2021
GabrielNagy
commented
Nov 4, 2021
GabrielNagy
commented
Nov 4, 2021
GabrielNagy
force-pushed
the
facter-impl
branch
2 times, most recently
from
f490be6
to
0c3a14a
Compare
ekohl
reviewed
Nov 5, 2021
There was a problem hiding this comment.
Overall 👍
What is your next step? Implement setting a different default should be done somewhere, but what's the appropriate place?
I'm also looking at how to best set it. Right now the user should either implement the same compatibility code or force a new enough version. Does supporting an implementation that prefers rspec but falls back to facter on older versions make sense?
GabrielNagy
force-pushed
the
facter-impl
branch
2 times, most recently
from
8075ac3
to
0ba5f75
Compare
I see that the puppet-nginx module for example uses the spec helper from https://github.com/voxpupuli/voxpupuli-test/blob/master/lib/voxpupuli/test/spec_helper.rb, so maybe that could be a good place?
I think falling back to |
ekohl
reviewed
Nov 5, 2021
GabrielNagy
force-pushed
the
facter-impl
branch
from
0ba5f75
to
71f081b
Compare
Starting with versions 7.12.0/6.25.0, Puppet was changed not to directly depend on Facter anymore, but to use a `Puppet::Runtime` implementation instead (e.g. calls to `Facter` were changed to `Puppet.runtime[:facter]` to allow for pluggable Facter backends). rspec-puppet stubs facts from facterdb by setting custom facts with higher weights, meaning that Facter 4 will still resolve the underlying core facts (which is by design), leading to noticeable performance hits when compiling catalogs with Facter 4 as opposed to Facter 2 (which just returned the custom fact). This means we can achieve a pretty big performance improvement with rspec-puppet by registering a custom Facter implementation that bypasses Facter altogether and just saves facts to hash. This behavior cand be activated by setting `facter_implementation` to `rspec` in `RSpec.configure`. By default, the setting has the value of `facter` which maintains the old behavior of going through Facter. If `rspec` is set but the Puppet version does not support Facter implementations, rspec will warn and fall back to using Facter.
GabrielNagy
force-pushed
the
facter-impl
branch
from
71f081b
to
48c5605
Compare
|
@ekohl I think this is pretty much done, let me know if I missed any of your suggestions. Thanks for the reviews! |
ekohl
approved these changes
Nov 8, 2021
luchihoratiu
approved these changes
Nov 10, 2021
I opened voxpupuli/voxpupuli-test#62 to experiment with this. |
|
Hi people. I merged and released the change from @ekohl . This passed on our nginx module: voxpupuli/puppet-nginx#1485 I tried the same on our bird module and a single test fails: I saw similar issues in the past when we had a broken fact, but I cannot remember the details. This is reproducible with the rspec facter implementation. The mentioned puppet code: I guessed that the facts from facterdb don't contain the legacy facts osfamily/operatingsystem, but they do: the mentioned puppet code is a serice resource: if $manage_service {
service { $daemon_name_v4:
ensure => $service_v4_ensure,
enable => $service_v4_enable,
hasrestart => false,
restart => '/usr/sbin/birdc configure',
pattern => $daemon_name_v4,
require => Package[$package_name_v4],
}
}So I'm not sure why it fails. The nginx module also has Archlinux in the metadata.json, but the tests seem to pass. |
|
It is an interesting case. When I change it to call pry: it do
require 'pry' ; binding.pry
is_expected.not_to contain_yumrepo('bird')
endRun it as So somehow the facts are not being set. I'm not sure, but one warning is interesting: However, it really appears to only be the first testcase within the nesting. If I add another one before it, that fails and then the next testcase (the one that now fails) does pass. Then I call pry again and see: So not having facts there may be a false positive. The next thing I checked if it's actually related to the OS at all. So I ran When you set |
|
@bastelfreak @ekohl I just opened #19 which appears to fix this issue; can you take a look and confirm? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Starting with versions 7.12.0/6.25.0, Puppet was changed not to directly
depend on Facter anymore, but to use a
Puppet::Runtimeimplementationinstead (e.g. calls to
Facterwere changed toPuppet.runtime[:facter]to allow for pluggable Facter backends).rspec-puppet stubs facts from facterdb by setting custom facts with
higher weights, meaning that Facter 4 will still resolve the underlying
core facts (which is by design), leading to noticeable performance hits
when compiling catalogs with Facter 4 as opposed to Facter 2 (which just
returned the custom fact).
This means we can achieve a pretty big performance improvement with
rspec-puppet by registering a custom Facter implementation that bypasses
Facter altogether and just saves facts to hash.
This behavior cand be activated by setting
facter_implementationtorspecinRSpec.configure. By default, the setting has the value offacterwhich maintains the old behavior of going through Facter.