Jira (FACT-1015) deprecation of 'facter --puppet' removes critically necessary functionality

45 views
Skip to first unread message

Jo Rhett (JIRA)

unread,
May 22, 2015, 2:53:30 AM5/22/15
to puppe...@googlegroups.com
Jo Rhett created an issue
 
Facter / Bug FACT-1015
deprecation of 'facter --puppet' removes critically necessary functionality
Issue Type: Bug Bug
Assignee: Unassigned
Created: 2015/05/21 11:53 PM
Priority: Major Major
Reporter: Jo Rhett

So while I understand the goal behind

FACT-96 . there's a significant loss of functionality there. I see no method of retrieving a single value, which is very highly used within external scripts which make use of puppet plugin-synced facts.

$ facter system_uptime
{"seconds"=>532, "hours"=>0, "days"=>0, "uptime"=>"0:08 hours"}

Note in this context, just from my personal source archives I found more than 1000 uses of this exact functionality, and I can attest to tens of thousands more uses at companies where I am not allowed to take their source offsite on my laptop.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d)
Atlassian logo

Josh Cooper (JIRA)

unread,
May 22, 2015, 12:17:16 PM5/22/15
to puppe...@googlegroups.com
Josh Cooper commented on Bug FACT-1015
 
Re: deprecation of 'facter --puppet' removes critically necessary functionality

I could have sworn we already had a ticket on this, but I can't find it. Yep, the functionality is important, and something we plan on addressing before removing the --puppet option.

Kylo Ginsberg (JIRA)

unread,
May 22, 2015, 6:47:16 PM5/22/15
to puppe...@googlegroups.com

Ah I saw the comment on

FACT-96 but missed this ticket initially. So I'll ask here

Jo Rhett I didn't connect your comment to your example. Specifically, system_uptime is a built-in fact, not a plugin-synced fact. Are you asking about the ability to get an individual element of a structured fact (like system_uptime) from the command-line?

If so, with facter 3, you can use a dotted syntax on the command line, e.g.

$ ./bin/facter system_uptime
{
  days => 27,
  hours => 669,
  seconds => 2410743,
  uptime => "27 days"
}
$ ./bin/facter system_uptime.days
27

Jo Rhett (JIRA)

unread,
May 23, 2015, 12:34:17 PM5/23/15
to puppe...@googlegroups.com
Jo Rhett commented on Bug FACT-1015

Kylo: I'm asking about the ability to get ANY fact provided through puppet pluginsync on the command line after --puppet is removed. String, structured, etc.

In my experience it is very common practice to make new facts available, and then use them in shell scripts run on the host – say for cron jobs, scripts invoked by jenkins, etc.

The facter 3 functionality shown above would be nice, but is nearly irrelevant without the ability to see Puppet's facts. There's only a few structured facts available by default.

Kylo Ginsberg (JIRA)

unread,
May 26, 2015, 12:17:15 AM5/26/15
to puppe...@googlegroups.com

Jo Rhett gotcha, and that makes perfect sense. Given that I think I'll move this to the PUP project and adjust the summary to something like "'puppet facts' should allow retrieval of a specified fact".

Once that is done, there could be a follow-on effort to further extend "puppet facts" to provide something like facter 3's dotted syntax for pulling out an individual element of a structured fact. That really needs to be sanity-checked for UX consistency across the various projects though, so out of scope for this ticket.

Michael Smith (JIRA)

unread,
Jun 29, 2015, 5:15:18 PM6/29/15
to puppe...@googlegroups.com

Other functionality we should support is dumping yaml - which should be provided by puppet facts --render_as yaml - and providing just the facts rather than the whole facts node indirector response (which puts facts in the values key).

Kylo Ginsberg (JIRA)

unread,
Jun 29, 2015, 8:55:10 PM6/29/15
to puppe...@googlegroups.com
Kylo Ginsberg moved an issue
 
Puppet / Improvement PUP-4798
Change By: Kylo Ginsberg
Issue Type: Bug Improvement
Key: FACT PUP - 1015 4798
Project: Facter Puppet

Kylo Ginsberg (JIRA)

unread,
Jun 29, 2015, 8:55:15 PM6/29/15
to puppe...@googlegroups.com
Kylo Ginsberg updated an issue
 
Change By: Kylo Ginsberg
Summary: deprecation of  ' facter -- puppet  facts '  removes critically necessary functionality  should allow retrieval of a specified fact

Jo Rhett (JIRA)

unread,
Jun 29, 2015, 9:09:13 PM6/29/15
to puppe...@googlegroups.com
Jo Rhett updated an issue
 
Puppet / Bug PUP-4798
'puppet facts' should restore retrieval of a specified fact

No, I'm sorry but whitewashing this into an Improvement is not acceptable.

You are removing functionality which works today, the removal of which will break hundreds of customers, and at least three dozen modules on the Puppet Forge. This is a bug. Restoring the functionality is not an improvement, it's fixing your bug.

Change By: Jo Rhett
Issue Type: Improvement Bug
Summary: 'puppet facts' should  allow  restore  retrieval of a specified fact

Jo Rhett (JIRA)

unread,
Jun 29, 2015, 9:10:16 PM6/29/15
to puppe...@googlegroups.com
Jo Rhett updated an issue

I'm restoring the original title since the title change was an attempt to whitewash this bug into a feature request, which it most absolutely is not.

Change By: Jo Rhett
Summary: deprecation of ' facter -- puppet  facts '  should restore retrieval of a specified fact  removes critically necessary functionality

Steve Barlow (JIRA)

unread,
Jul 1, 2015, 5:15:15 PM7/1/15
to puppe...@googlegroups.com

Steve Barlow (JIRA)

unread,
Jul 1, 2015, 5:18:23 PM7/1/15
to puppe...@googlegroups.com
Steve Barlow updated an issue
Change By: Steve Barlow
Story Points: 3
QA Highest Test Level: Acceptance

Steve Barlow (JIRA)

unread,
Jul 1, 2015, 5:19:20 PM7/1/15
to puppe...@googlegroups.com

Kylo Ginsberg (JIRA)

unread,
Jul 6, 2015, 2:50:08 PM7/6/15
to puppe...@googlegroups.com
Kylo Ginsberg commented on Bug PUP-4798
 
Re: deprecation of 'facter --puppet' removes critically necessary functionality

After more dialog, an alternate approach might be:

  • since 'facter' as the owner of facts is reasonably intuitive (compared to 'puppet facts')
  • short-term: modify facter to look in puppet's default plugin sync locations for custom and external facts
  • longer-term: look into a config file for facter (again, treating facter as the owner of facts) and have facter tell puppet where to put them

Short-term, that would break the circular dependency concern of fact-96, but wouldn't address usage of 'facter -p' at sites that override the plugin sync directories.

This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c)
Atlassian logo

Kylo Ginsberg (JIRA)

unread,
Jul 8, 2015, 12:14:05 PM7/8/15
to puppe...@googlegroups.com
Kylo Ginsberg commented on Bug PUP-4798

Okay, I got nodes on the above in meatspace. So moving this back to FACT

Kylo Ginsberg (JIRA)

unread,
Jul 8, 2015, 12:17:02 PM7/8/15
to puppe...@googlegroups.com
Kylo Ginsberg moved an issue
Change By: Kylo Ginsberg
Fix Version/s: PUP 4.2.1
Fix Version/s: FACT 3.0.2
Key: PUP FACT - 4798 1111
Project: Puppet Facter

Jo Rhett (JIRA)

unread,
Jul 8, 2015, 3:24:05 PM7/8/15
to puppe...@googlegroups.com

look into a config file for facter (again, treating facter as the owner of facts) and have facter tell puppet where to put them

Short-term, that would break the circular dependency concern of fact-96, but wouldn't address usage of 'facter -p' at sites that override the plugin sync directories.

These two sentences seem pretty obviously related. Have facter check the puppet configuration for the plugin sync directories?

Or, document that if you override the plugin sync directories you must also set facter's load path?

Michael Smith (JIRA)

unread,
Jul 8, 2015, 3:57:03 PM7/8/15
to puppe...@googlegroups.com

Eric Thompson (JIRA)

unread,
Jul 8, 2015, 7:10:23 PM7/8/15
to puppe...@googlegroups.com
Eric Thompson updated an issue
 
Change By: Eric Thompson
QA Risk Severity: High
QA Risk Severity Reason: escalation-ish.  need pluginsync'd facts from facter
QA Risk Assessment: High

Michael Smith (JIRA)

unread,
Jul 9, 2015, 12:45:09 PM7/9/15
to puppe...@googlegroups.com
 
Re: deprecation of 'facter --puppet' removes critically necessary functionality

To summarize a short in-person conversation with Branan Riley:

In response to my own comment yesterday, we need to gracefully handle failures to load custom facts (pretty sure we already do, but worth verifying) and move people to modules to requiring Puppet explicitly if they need it and want to be usable. Tempted to make this an INFO level message, rather than a warning.

Kylo Ginsberg (JIRA)

unread,
Jul 9, 2015, 1:06:08 PM7/9/15
to puppe...@googlegroups.com

Agreed on gracefully handling failures to load custom facts.

As for log level, I'd incline the other way, i.e. to making it a warning or error if custom facts fail to load - that is something that the admin should fix. Otoh, it may be that it's super common and we don't want to spam people who've been blithely living with custom fact load failures for years. Perhaps we should look at what facter 2 does as input to the log level question.

As for resetting plugin*dest, IIRC Josh Cooper suggested that those two settings couldn't be productively or correctly set in puppet anyway, meaning maybe no one is doing so. Not sure if I got that right, or how to validate that though. So it couldn't hurt to reset those settings in puppet_agent.

Branan Riley (JIRA)

unread,
Jul 9, 2015, 1:07:07 PM7/9/15
to puppe...@googlegroups.com
Branan Riley commented on Bug FACT-1111

I'm fine with saying that those facts need to explicitly 'require puppet'. We probably do need to make sure that puppet is in our $LOAD_PATH, though.

Branan Riley (JIRA)

unread,
Jul 9, 2015, 1:08:19 PM7/9/15
to puppe...@googlegroups.com
Branan Riley commented on Bug FACT-1111

Kylo Ginsberg Currently we reset libdir. If somebody had (for some reason) set both libdir and plugindest to the same value (even though plugindest defaults to libdir), we'd be causing breakages in the upgrade process. Given it's a one-liner to fix plugindest where we fixup libdir, it seems a worthwhile "just in case"... but def is unrelated to this ticket.

Michael Smith (JIRA)

unread,
Jul 9, 2015, 1:12:10 PM7/9/15
to puppe...@googlegroups.com

Facts that rely on things like Puppet::Util would work with facter -p, because Facter actually does require 'puppet'. So this still breaks some facts that would've worked with facter -p, but in a fairly trivial way.

Peter Huene (JIRA)

unread,
Jul 9, 2015, 1:26:08 PM7/9/15
to puppe...@googlegroups.com
Peter Huene commented on Bug FACT-1111

re: custom facts failing to load, currently we log an error in factor along with any exception message; --trace will cause the output to include the back trace, like we would have from Ruby Facter. I think that's sufficient and desirable.

Josh Cooper (JIRA)

unread,
Jul 9, 2015, 1:40:19 PM7/9/15
to puppe...@googlegroups.com
Josh Cooper commented on Bug FACT-1111

re: plugindest, if plugindest is changed from the default, then puppet agent won't be able to load pluginsynced code: see https://projects.puppetlabs.com/issues/18459. The reason is because libdir is not also updated to reflect the new location, and the hook for that setting is what changes puppet's $LOAD_PATH. So tl; dr, puppet agent will not work if you change the default plugindest.

The other thing to consider is pluginfactsdest for pluginsync'ed external facts. If that value was changed, I think puppet will still work (could tell facter to load those external facts). But I'm not sure if facter -p would have worked previously.

Peter Huene (JIRA)

unread,
Jul 9, 2015, 1:47:11 PM7/9/15
to puppe...@googlegroups.com
Peter Huene commented on Bug FACT-1111

From Michael's link, it doesn't look like Facter 2.x added pluginfactsdest to the external search paths, so I don't think pluginsync'd external facts worked even with -p in 2.x. Still, that's something we should get working in 3.0.2, even if it's for the default location only.

Josh Cooper (JIRA)

unread,
Jul 9, 2015, 2:26:04 PM7/9/15
to puppe...@googlegroups.com

Jo Rhett (JIRA)

unread,
Jul 9, 2015, 4:01:09 PM7/9/15
to puppe...@googlegroups.com
Jo Rhett commented on Bug FACT-1111

Peter: that is completely untrue. Not only have I written dozens of modules which sync down facts that are used in bash scripts on the host, but I've found that dozens of community modules I depend on do similar things, pushing down facts to be used for cron jobs, etc.

That is why I opened this issue. This did and does today work with Facter 2.

Josh Cooper (JIRA)

unread,
Jul 9, 2015, 4:17:05 PM7/9/15
to puppe...@googlegroups.com
Josh Cooper commented on Bug FACT-1111

Jo Rhett you are confusing pluginsynced custom vs pluginsynced external facts. The former did work previously in 2.x, the latter did not (see

FACT-696 ). Unfortunately we don't have great names for the three variations of facts: pluginsynced custom vs pluginsynced external vs non-pluginsynced external...

Michael Smith (JIRA)

unread,
Jul 9, 2015, 5:50:10 PM7/9/15
to puppe...@googlegroups.com

Current modules that expect Puppet to be set

puppetlabs-apache-0.3.0/spec/fixtures/modules/stdlib/lib/facter/puppet_vardir.rb
puppetlabs-concat-1.0.0/lib/facter/concat_basedir.rb
puppetlabs-concat-1.0.0-rc1/lib/facter/concat_basedir.rb
puppetlabs-concat-1.0.1/lib/facter/concat_basedir.rb
puppetlabs-concat-1.0.2/lib/facter/concat_basedir.rb
puppetlabs-concat-1.0.3/lib/facter/concat_basedir.rb
puppetlabs-concat-1.0.4/lib/facter/concat_basedir.rb
puppetlabs-concat-1.1.0/lib/facter/concat_basedir.rb
puppetlabs-concat-1.1.0-rc1/lib/facter/concat_basedir.rb
puppetlabs-concat-1.1.1/lib/facter/concat_basedir.rb
puppetlabs-concat-1.1.2/lib/facter/concat_basedir.rb
puppetlabs-concat-1.2.0/lib/facter/concat_basedir.rb
puppetlabs-concat-1.2.1/lib/facter/concat_basedir.rb
puppetlabs-concat-1.2.2/lib/facter/concat_basedir.rb
puppetlabs-firewall-1.4.0/lib/facter/iptables_persistent_version.rb
puppetlabs-firewall-1.5.0/lib/facter/iptables_persistent_version.rb
puppetlabs-keystone-2.1.0/spec/fixtures/modules/stdlib/lib/facter/puppet_vardir.rb
puppetlabs-mysql-2.2.0/spec/fixtures/modules/stdlib/lib/facter/puppet_vardir.rb
puppetlabs-nodejs-0.1.1/spec/fixtures/modules/stdlib/lib/facter/puppet_vardir.rb
puppetlabs-nodejs-0.2.0/spec/fixtures/modules/stdlib/lib/facter/puppet_vardir.rb
puppetlabs-pe_upgrade-1.0.0/spec/fixtures/modules/stdlib/lib/facter/puppet_vardir.rb
puppetlabs-policy_engine-0.0.1/lib/facter/policy_engine.rb
puppetlabs-policy_engine-0.0.1/lib/facter/puppet_vardir.rb
puppetlabs-policy_engine-0.0.2/lib/facter/policy_engine.rb
puppetlabs-policy_engine-0.0.2/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-2.3.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-2.3.1/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-2.3.2/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-2.3.3/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-2.4.0/lib/facter/facter_dot_d.rb
puppetlabs-stdlib-2.4.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-2.5.0/lib/facter/facter_dot_d.rb
puppetlabs-stdlib-2.5.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-2.5.1/lib/facter/facter_dot_d.rb
puppetlabs-stdlib-2.5.1/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-2.6.0/lib/facter/facter_dot_d.rb
puppetlabs-stdlib-2.6.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-3.0.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-3.0.1/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-3.1.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-3.1.1/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-3.2.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-3.2.1/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-3.2.2/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-4.1.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-4.2.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-4.2.1/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-4.2.2/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-4.3.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-4.3.2/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-4.4.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-4.5.0/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-4.5.1/lib/facter/facter_dot_d.rb
puppetlabs-stdlib-4.5.1/lib/facter/puppet_vardir.rb
puppetlabs-stdlib-4.6.0/lib/facter/facter_dot_d.rb
puppetlabs-stdlib-4.6.0/lib/facter/puppet_vardir.rb

Looks like just a few we'd have to patch up.

Michael Smith (JIRA)

unread,
Jul 10, 2015, 7:04:21 PM7/10/15
to puppe...@googlegroups.com
Michael Smith updated an issue
 
Change By: Michael Smith
So while I understand the goal behind FACT-96. there's a significant loss of functionality there.  I see no method of retrieving a single value, which is very highly used within external scripts which make use of puppet plugin-synced facts. 

{code}
$ facter system_uptime
{"seconds"=>532, "hours"=>0, "days"=>0, "uptime"=>"0:08 hours"}
{code}

Note in this context, just from my personal source archives I found more than 1000 uses of this exact functionality, and I can attest to tens of thousands more uses at companies where I am not allowed to take their source offsite on my laptop.


Resolution: we're restoring `facter -p` in Facter 3.0.2, with plans to address FACT-96 more completely in the future.

Hailee Kenney (JIRA)

unread,
Jul 13, 2015, 11:36:37 AM7/13/15
to puppe...@googlegroups.com
Hailee Kenney assigned an issue to qa
Change By: Hailee Kenney
Status: Ready for  CI  Test
Assignee: qa

Michael Smith (JIRA)

unread,
Jul 13, 2015, 5:23:06 PM7/13/15
to puppe...@googlegroups.com
 
Re: deprecation of 'facter --puppet' removes critically necessary functionality

This was incorrectly put into master instead of stable, wait on verifying until I cherry-pick up to stable.

Michael Smith (JIRA)

unread,
Jul 13, 2015, 5:23:30 PM7/13/15
to puppe...@googlegroups.com

Michael Smith (JIRA)

unread,
Jul 13, 2015, 5:23:31 PM7/13/15
to puppe...@googlegroups.com

Kylo Ginsberg (JIRA)

unread,
Jul 13, 2015, 5:41:07 PM7/13/15
to puppe...@googlegroups.com
Kylo Ginsberg updated an issue
 
Restore 'facter --puppet'
Change By: Kylo Ginsberg
Summary: deprecation of Restore  'facter --puppet'  removes critically necessary functionality

Kylo Ginsberg (JIRA)

unread,
Jul 13, 2015, 6:07:11 PM7/13/15
to puppe...@googlegroups.com
Kylo Ginsberg updated an issue
This ticket went through some evolution, so I'll attempt to summarize.

The '--puppet' option to facter introduces a circular dependency between facter and puppet, so we had plans to break that cycle. Specifically, in 2.4.4 we introduced a deprecation notice for 'facter --puppet', and in facter 3.0 we removed it (by not reimplementing it). Our recommendation was to use 'puppet facts' instead.

However, as raised in this ticket and in some conversations in IRC and meatspace, there are a couple concerns with that deprecation and removal:
* 'puppet facts' doesn't implement the full set of functionality, especially the ability to specify a single fact to retrieve
* there's a fair bit of scripting around the current behavior, and we really need to have the full replacement behavior in place for an overlapping period of time to support an easy transition away from the deprecated behavior
* deprecation or not, we haven't addressed additional functionality such as specifying elements of a structured fact from the CLI

So  for the time being, we're restoring 'facter --puppet'. Ultimately, we still want to break the circular dependency between facter and puppet, but we won't do so until we have a clear path forward for how the two interact.

------------------

Original description below.

------------------
So
 while I understand the goal behind FACT-96. there's a significant loss of functionality there.  I see no method of retrieving a single value, which is very highly used within external scripts which make use of puppet plugin-synced facts. 


{code}
$ facter system_uptime
{"seconds"=>532, "hours"=>0, "days"=>0, "uptime"=>"0:08 hours"}
{code}

Note in this context, just from my personal source archives I found more than 1000 uses of this exact functionality, and I can attest to tens of thousands more uses at companies where I am not allowed to take their source offsite on my laptop.

Resolution: we're restoring `facter -p` in Facter 3.0.2, with plans to address FACT-96 more completely in the future.

Michael Smith (JIRA)

unread,
Jul 13, 2015, 7:25:15 PM7/13/15
to puppe...@googlegroups.com
Michael Smith assigned an issue to qa
Change By: Michael Smith
Status: Ready for  CI  Test
Assignee: Michael Smith qa

Sean Griffin (JIRA)

unread,
Jul 14, 2015, 12:25:07 PM7/14/15
to puppe...@googlegroups.com
Sean Griffin assigned an issue to Sean Griffin
Change By: Sean Griffin
Assignee: qa Sean Griffin

Sean Griffin (JIRA)

unread,
Jul 21, 2015, 2:36:07 AM7/21/15
to puppe...@googlegroups.com
Sean Griffin commented on Bug FACT-1111
 
Re: Restore 'facter --puppet'

Additional test cases:
1. pluginsynced external fact
2. facter cmds in a system absent puppet

1. pluginsynced external fact:
tested on centos-7-x86_64

On the Master root directory I (1) created a module: hellofact, containing
an external fact, hellofact.rb, which return string "Hello facter!",
(2) built it with 'puppet module build hellofact', (3) installed it with
install hellofact/pkg/sean-hellofact-0.1.0.tgz, (4) called 'puppet agent -t'.
On the agent node I also called 'puppet agent -t'.

On both agent and master, facter behaves the same way when fetching
the external fact hellofact. When called with --puppet, the fact is displayed.
When called without --puppet, the fact is not displayed.

[root@t08kvwquaxnqa35 ~]# facter -p hellofact
Hello facter!
[root@t08kvwquaxnqa35 ~]# facter hellofact
 
[root@t08kvwquaxnqa35 ~]#

2. facter cmds in a system absent puppet
Running facter with no puppet.

Tested on fedora-20-x86_64
stable branch 7/22/15 2200
3.0.1 (commit fe9df8a0719361c88fb3726dc535d04b80759871)

In this test, I compiled facter on a Fedora vm and ran it without puppet installed. facter -p generated a the following warning to stderr but did not cause failure (very nice):

2015-07-20 22:30:31.402088 WARN puppetlabs.facter - Could not load puppet; some facts may be unavailable: cannot load such file – puppet

Except for that, the output from invocations with and without the -p option are the same. Tested with --custom-dir, --external-dir

[root@yiyjcvx1os3k4sx bin]# pwd
/root/facter/release/bin
[root@yiyjcvx1os3k4sx bin]# ls
facter  facts.d  f.out  fp.out  libfacter_test
[root@yiyjcvx1os3k4sx bin]# PATH=.:$PATH
[root@yiyjcvx1os3k4sx bin]# facter --version
3.0.1 (commit fe9df8a0719361c88fb3726dc535d04b80759871)
[root@yiyjcvx1os3k4sx bin]# ### stable branch of facter, leatherman
[root@yiyjcvx1os3k4sx bin]#
[root@yiyjcvx1os3k4sx bin]# facter os.family
[root@yiyjcvx1os3k4sx bin]# facter -p os.family
2015-07-20 22:30:31.402088 WARN  puppetlabs.facter - Could not load puppet; some facts may be unavailable: cannot load such file -- puppet
RedHat
[root@yiyjcvx1os3k4sx bin]# cat facts.d/hellofact.rb
Facter.add("hellofact") do
  setcode do
    Facter::Core::Execution.exec("echo hello factor!\n")
  end
end
 
[root@yiyjcvx1os3k4sx bin]# facter --custom-dir facts.d/ hellofact
hello factor!
[root@yiyjcvx1os3k4sx bin]# facter -p --custom-dir facts.d/ hellofact
2015-07-20 22:31:40.677669 WARN  puppetlabs.facter - Could not load puppet; some facts may be unavailable: cannot load such file -- puppet
hello factor!
[root@yiyjcvx1os3k4sx bin]
[root@yiyjcvx1os3k4sx bin]# cat facts.d/hf
#! /bin/sh
echo "key=value"
[root@yiyjcvx1os3k4sx bin]# ls -l facts.d/
total 8
-rw-r--r--. 1 root root 108 Jul 20 22:21 hellofact.rb
-rwxr-xr-x. 1 root root  28 Jul 20 22:57 hf
[root@yiyjcvx1os3k4sx bin]# facter --external-dir facts.d/ key
value
[root@yiyjcvx1os3k4sx bin]# facter -p --external-dir facts.d/ key
2015-07-20 23:04:47.886185 WARN  puppetlabs.facter - Could not load puppet; some facts may be unavailable: cannot load such file -- puppet
value
[root@yiyjcvx1os3k4sx bin]#

John Duarte (JIRA)

unread,
Jul 29, 2015, 6:45:08 PM7/29/15
to puppe...@googlegroups.com
John Duarte updated an issue
Change By: John Duarte
QA Status: Reviewed

Sean Griffin (JIRA)

unread,
Aug 11, 2015, 6:22:13 PM8/11/15
to puppe...@googlegroups.com
Sean Griffin assigned an issue to Unassigned
Change By: Sean Griffin
Assignee: Sean Griffin
Reply all
Reply to author
Forward
0 new messages