Issue #2157 has been updated by Jeff McCune.
Target version changed from 2.0.0 to 1.7.0
External facts are included in the 1.7.x branch in commit 9f3d8a94. I'm
re-targeting this ticket at 1.7.0 as a result.
See commit [9f3d8a94](https://github.com/puppetlabs/facter/commit/9f3d8a94)
-Jeff
Issue #2157 has been updated by Jeff McCune.
Adrien, you might want to check out some of the cleanup work we did.
In particular, the spec tests were doing a lot of filesystem IO which should
(must) be avoided when writing unit tests:
I think the patch in
Issue #2157 has been updated by Adrien Thebo.
I just want to comment that you guys rock for handling this.
Feature #2157: External fact support
https://projects.puppetlabs.com/issues/2157#change-65459
Author: Paul Nasrat
Status: Code Insufficient
Issue #2157 has been updated by Hailee Kenney.
Branch changed from
https://github.com/jeffweiss/facter/commits/ticket/master/2157-external_fact_support
to https://github.com/puppetlabs/facter/pull/244
Feature #2157: External fact support
Issue #2157 has been updated by Jeff Weiss.
Branch changed from
https://github.com/adrienthebo/facter/tree/ticket/master/2157-external_fact_support
to
https://github.com/jeffweiss/facter/commits/ticket/master/2157-external_fact_support
Rebased off master and moved work to
Issue #2157 has been updated by Jeff Weiss.
Current branch from ken-adrien-me (jeffweiss) currently relies on `json` gem.
Just reiterating `json` as an additional dep. As this gets closer to prime
time, we'll want to evaluate if we want to actually introduce that dependency
or handle it in
Issue #2157 has been updated by Adrien Thebo.
Branch changed from
https://github.com/kbarber/facter/tree/ticket/2157-external_fact_support to
https://github.com/adrienthebo/facter/tree/ticket/master/2157-external_fact_support
I've done a lot of work to split up Ken's work into a lot of small
Issue #2157 has been updated by Adrien Thebo.
Assignee deleted (Adrien Thebo)
Feature #2157: External fact support
https://projects.puppetlabs.com/issues/2157#change-62618
Author: Paul Nasrat
Status: Code Insufficient
Priority: Normal
Assignee:
Issue #2157 has been updated by Jeff Weiss.
Assignee set to Jeff Weiss
Needs
- rebase (off current tree?)
- review
- move addl functionality to atomic tickets pull reqs (eg powershell)
- squashed ?
We have docs already of what these external facts should look like with custom
facts
Issue #2157 has been updated by Jeff Weiss.
Target version changed from 2.0.0 to 2.X
Feature #2157: External fact support
https://projects.puppetlabs.com/issues/2157#change-62623
Author: Paul Nasrat
Status: Code Insufficient
Priority: Normal
Assignee:
Issue #2157 has been updated by Ken Barber.
Assignee changed from Ken Barber to Adrien Thebo
Moving cache back into another ticket - since Adrien wants to pick up the
external facts work. Cache is moving back to #4519.
Feature #2157: External fact
Issue #2157 has been updated by Ken Barber.
Subject changed from External fact support caching to External fact support
Feature #2157: External fact support
https://projects.puppetlabs.com/issues/2157
Author: Paul Nasrat
Status: Code Insufficient
Issue #2157 has been updated by Ken Barber.
Yury Zaytsev wrote:
Ken Barber wrote:
but I'm sure Redhat/Fedora repackagers may feel they want to modify it to
/usr/libexec to suit their 'standards'. *sigh*.
You bet!
-- RH Packager
Thats funny :-). So Redhats official position is:
Issue #2157 has been updated by Ken Barber.
Another thought - right now the configurability of this location is on the
command line - or via API. Maybe we need a configuration file where this path
is defined. This would at least provide a place for people to find out what the
path is easily
Issue #2157 has been updated by Ken Barber.
Looks like Solaris lacks /usr/libexec.
Feature #2157: External fact support in /etc/facter.d
https://projects.puppetlabs.com/issues/2157
Author: Paul Nasrat
Status: Code Insufficient
Priority: Normal
Assignee:
Issue #2157 has been updated by Ken Barber.
SLES 11 does _not_ have /usr/libexec
Gentoo still uses /usr/libexec it would seem ... but I think its being
deprecated.
OpenBSD has /usr/libexec ... which aligns with my BSD assumption.
Feature #2157:
Issue #2157 has been updated by Ken Barber.
I've now updated install.rb to create the necessary directory for external
facts - at the moment I'm just assuming for now:
/usr/lib/facter/ext
(And COMMON_APPDATA/Puppetlabs/facter/ext for windows)
I've also updated the rpm spec file to handle
Issue #2157 has been updated by Michael Stahnke.
I'm a jerk and thought about this more. I hate executable scripts in etc.
It's wrong. While FHS isn't clear, maybe we could do something better than put
it in etc. Something in /var/lib/facter/facts.d or /usr/share/facter/facts.d
makes
Issue #2157 has been updated by Yury Zaytsev.
Michael Stahnke wrote:
I'm a jerk and thought about this more. I hate executable scripts in etc.
It's wrong. While FHS isn't clear, maybe we could do something better than
put it in etc.
Yes, it doesn't feel right, but consider
1) rc.local
Issue #2157 has been updated by Ken Barber.
Michael Stahnke wrote:
I'm a jerk and thought about this more. I hate executable scripts in etc.
It's wrong. While FHS isn't clear, maybe we could do something better than
put it in etc. Something in /var/lib/facter/facts.d or
Issue #2157 has been updated by R.I. Pienaar.
The closest example of this in another application is actually:
/usr/lib/nagios/plugins/check_foo
+1, also where mcollective agents/plugins etc is on debian. I wanted to make
RH the same though the community didnt seem to like the change -
Issue #2157 has been updated by Yury Zaytsev.
/usr/lib/nagios/plugins/check_foo
AFAIK those are supposed to be sourced / run via the embedded Perl interpreter
or something like that. Putting executables in /usr/lib is bad style, that's
what /usr/libexec is for.
Issue #2157 has been updated by Yury Zaytsev.
/usr/share is architecture independent (which may or may not be true).
/var/lib is for variable ‘data’. So I would rule these out.
+1.
re: yes, /usr/share is supposed to be noarch. I don't know if exceptions are
allowed to this rule.
Issue #2157 has been updated by Ken Barber.
Yury Zaytsev wrote:
/usr/lib/nagios/plugins/check_foo
AFAIK those are supposed to be sourced / run via the embedded Perl
interpreter or something like that. Putting executables in /usr/lib is bad
style, that's what /usr/libexec is for.
Issue #2157 has been updated by Ken Barber.
Yury Zaytsev wrote:
/usr/lib/nagios/plugins/check_foo
AFAIK those are supposed to be sourced / run via the embedded Perl
interpreter or something like that. Putting executables in /usr/lib is bad
style, that's what /usr/libexec is for.
Oh
Issue #2157 has been updated by James Turnbull.
I'm comfortable with that as long as we make it configurable somehow I think.
Feature #2157: External fact support in /etc/facter.d
https://projects.puppetlabs.com/issues/2157
Author: Paul Nasrat
Status:
Issue #2157 has been updated by Yury Zaytsev.
Ken Barber wrote:
/usr/libexec is not mentioned in the FHS. Having said that - this is probably
the correct place on Mac OS X according to 'man hier'.
It used to be in FHS, but I have checked out the latest version and it was
removed indeed,
Issue #2157 has been updated by Ken Barber.
R.I. Pienaar wrote:
Are you suggesting we make this linux FHS compliant and put it elsewhere on
other OS to make it comply to their standards? That would be a mistake imho,
as would forcing linux standards on other unixen.
There are cases where
Issue #2157 has been updated by Yury Zaytsev.
Ken Barber wrote:
but I'm sure Redhat/Fedora repackagers may feel they want to modify it to
/usr/libexec to suit their 'standards'. *sigh*.
You bet!
-- RH Packager
Feature #2157: External fact support
Issue #2157 has been updated by Ken Barber.
I've committed some doc changes to a topic branch for puppet-doc:
https://github.com/kbarber/puppet-docs/commits/2157-external_fact_support
And asked Nick Fagerlund to take a look.
Feature #2157: External
Issue #2157 has been updated by Nick Fagerlund.
I've gone ahead and pushed the docs on this, since we have to put a version
caveat in this info anyway and I don't think having slightly-pre-release info
in the custom facts guide is a huge deal.
Feature
Issue #2157 has been updated by Ken Barber.
TypeError handling now done.
Feature #2157: External fact support in /etc/facter.d
https://projects.puppetlabs.com/issues/2157
Author: Paul Nasrat
Status: Code Insufficient
Priority: Normal
Assignee: Ken
Issue #2157 has been updated by Ken Barber.
Okay - so I've made paths configurable on the command line now, and I'm dealing
with automatically working them out depending on the OS.
The remaining tasks are largely:
* Dealing with creation of external script dir during installation.
* Handling
Issue #2157 has been updated by Ken Barber.
Adrien Thebo wrote:
Hi Ken,
I'm currently doing merges into facter en masse, and I was wondering if this
was actually ready for merge or not. Is the status of this ticket incorrect?
Nope - the status is incorrect. Last time I looked I don't have
Issue #2157 has been updated by Ken Barber.
Updates to my branch since last comment:
* Changed logic so a TTL of zero means never cache, and -1 means cache forever.
This got rid of a couple of oddities in how we were treating absent TTL with a
zero. This is less surprisingly as well IMHO.
*
Issue #2157 has been updated by Nigel Kersten.
Ken Barber wrote:
* Changes cache serialization to use Marshal not YAML. This file is internal
anyway and under heavy writes I saw much better performance. I tried just
'writing at the end' but Facter has multiple entry/exit points its hard to
Issue #2157 has been updated by Ken Barber.
Nigel Kersten wrote:
Ken Barber wrote:
* Changes cache serialization to use Marshal not YAML. This file is
internal anyway and under heavy writes I saw much better performance. I
tried just 'writing at the end' but Facter has multiple
Issue #2157 has been updated by Nigel Kersten.
To be clear, I'm not sure how big a problem this actually is, but i know this
is one reason we've moved away from marshal in Puppet.
Given it's a cache, it may be fine to use it for performance reasons and simply
wipe it out if you can't read
Issue #2157 has been updated by Ken Barber.
Added support for --timing in external scripts. It also reports if the cache
was used or not as well.
This change means I've re-factored the way we use 'results' by introducing a
wrapper method that we call internally to get results. This wrapper
Issue #2157 has been updated by Ken Barber.
Added poweshell, com exe handling for windows. Powershell handling is done
through a new parser since I need to special case the calling of such scripts
(prefix of 'powershell ' to the exec call) and I anticipate other special
casing most
Issue #2157 has been updated by Yury Zaytsev.
Ken Barber wrote:
Now I need to deal with default paths for windows as /tmp
On Windows, %TEMP% environment variable should contain the location of the
folder for temporary data.
/etc/facter/facts.d are not sufficient for that platform.
Issue #2157 has been updated by Ken Barber.
Hey thanks for the help Yury.
In regards to temp space - something I haven't yet discussed in the ticket is
that /tmp is an insecure place to have a named file so I'm probably going to
need to change that as well on Unix to a proper data area.
Issue #2157 has been updated by Yury Zaytsev.
Hi!
Ken Barber wrote:
In regards to temp space - something I haven't yet discussed in the ticket is
that /tmp is an insecure place to have a named file so I'm probably going to
need to change that as well on Unix to a proper data area.
Not
Issue #2157 has been updated by Ken Barber.
Not sure I understand you correctly. On Unix-like platforms I am generally
doing mktemp and setting permissions on the resulting directory to make sure
that only the invoking user can write to it. A portable way to do it from a
shell script
Issue #2157 has been updated by Ken Barber.
Added batch file handling for ScriptParser in windows. All tests succeed in
Windows now.
Will need to add handling for ps1 (powershell), com and exe files which means
I'll probably modify match_extension to take an array.
Issue #2157 has been updated by Ken Barber.
Branch changed from luke/tickets/master/2157-external_fact_support to
kbarber/tickets/master/2157-external_fact_support
Fixed infinite loop case as per RI's last comment.
Feature #2157: External fact support
Issue #2157 has been updated by Ken Barber.
Found small typo/bug in parser.rb (ttl does not exist in parser - should use
cache.ttl(filename). Now fixed in my branch.
I've add a new example that tries to return results with an unprimed cache to
ensure we catch this kind of thing again.
Issue #2157 has been updated by Ken Barber.
I've committed a patch with tests that removes extraneous whitespace from
LHS/RHS entries. This caught me when trying to use these formats and I'd
anticipate most users would be less surprised in this case.
Issue #2157 has been updated by Luke Kanies.
Assignee changed from Luke Kanies to Ken Barber
Branch set to luke/tickets/master/2157-external_fact_support
Ok, I've updated my branch to use /etc/facter/facts.d instead of /etc/facts.d.
It still caches files in /tmp/facts_cache.yaml.
None of this
Issue #2157 has been updated by R.I. Pienaar.
I had a bit of nasty logic in the code I initially submitted, we need a retry
count or something here:
https://github.com/lak/facter/blob/a53d7d9e5ba9985b27b3b80e83c998bdae5928d6/lib/facter/util/parser.rb#L94-99
to avoid a infinite loop if JSON
Issue #2157 has been updated by Michael Stahnke.
Assignee changed from Michael Stahnke to Luke Kanies
The more I've looked into this the more I've learned that the FHS isn't clear.
I think in order to not violate the principle of least surprise, we should
place it in etc. Ideally something
Issue #2157 has been updated by Luke Kanies.
Michael Stahnke wrote:
The more I've looked into this the more I've learned that the FHS isn't
clear. I think in order to not violate the principle of least surprise, we
should place it in etc. Ideally something like /etc/facter/facts.d Note
Issue #2157 has been updated by Luke Kanies.
Assignee changed from Luke Kanies to Michael Stahnke
Assigning to Mike because he's going to marshall people to figure out where
these various files should go.
Feature #2157: External fact support in
Issue #2157 has been updated by Yury Zaytsev.
Luke Kanies wrote:
* Where should the facts go? E.g., /etc/facts.d, /etc/facter.d, /var/, ?
Is it possible to make this configurable at the package build time?
I would say **/etc/facter.d** makes sense on RHEL if these facts are mostly
Issue #2157 has been updated by James Turnbull.
Questions/Answers:
1. Where should the facts go? E.g., /etc/facts.d, /etc/facter.d, /var/, ?
/etc/facter.d/
2. Should we support scripts, or just plain data like yaml?
Both - be like Nagios plugins - anything that outputs data that facter can
Issue #2157 has been updated by James Turnbull.
I think cache should be /var/tmp perhaps - FHS for /var/tmp -
http://www.pathname.com/fhs/2.2/fhs-5.15.html
Feature #2157: External fact support in /etc/facter.d
https://projects.puppetlabs.com/issues/2157
Issue #2157 has been updated by Nigel Kersten.
Luke Kanies wrote:
I've got a version of this in my tickets/master/2157-external_fact_support
branch, and I've sent it to the list. We need to make a couple of decisions:
* Where should the facts go? E.g., /etc/facts.d, /etc/facter.d,
Issue #2157 has been updated by Luke Kanies.
One other thing I forgot to mention - there's no real relationship in the
current code between file names and fact names.
That is, you could have a file at /etc/facts.d/foo.yaml that set facts named
bar, baz, and boo, but nothing named foo.
This
Issue #2157 has been updated by R.I. Pienaar.
Luke Kanies wrote:
One other thing I forgot to mention - there's no real relationship in the
current code between file names and fact names.
That is, you could have a file at /etc/facts.d/foo.yaml that set facts named
bar, baz, and boo, but
Issue #2157 has been updated by Luke Kanies.
And another:
The directory loader should actually be able to load facts from multiple
directories. E.g., it should default to /etc/facter.d and ~/.facter.d for
non-root users.
There's no reason to restrict it to just one directory.
automatically so that I can easily write custom facts.
Given I have a configured directory for scripting facts
When a executable script that returns a key value pair is executed
Then the fact should be available in facter
Feature #2157: External fact support in /etc
61 matches
Mail list logo
