Issue #17156 has been updated by Nick Fagerlund.
So I've thought about this a little more.
Principles:
* Puppet doc, in its "reference" mode, should only document components that are
**installed.**
* Plugins cached by puppet agent during a run aren't installed; they're a
temporary, volatile reflection of what's installed on the master.
* But plugins in every environment on the master are all installed! And our
solution for reading everything in every environment was to copy it all to the
master's libdir.
* Dunno what to say about puppet apply except that it sort of cares about
environments, but in practice it really doesn't.
So in conclusion:
* Having puppet doc read plugins from the **agent's** libdir is wrong.
* Having it read plugins from the **master's** libdir is right.
* Obviously the results will be stupid if the agent and the master share a
libdir, just like everything else gets stupid.
* And what it's probably actually doing is using the libdir from the `[user]`
config block, which is approximately as wrong as using the agent's libdir.
So given that... I suspect it makes sense to switch puppet doc to master run
mode. That way, the theoretical users who're generating docs for their custom
types and functions will get the correct behavior pretty much no matter what.
* If they're doing this on the puppet master, it'll document all plugins from
all environments, as expected.
* If they're doing it on a puppet apply standalone node, most users are
probably putting their settings in `[main]` instead of `[user]` (that's a
hunch) and leaving `[master]` blank, so since master has no secret sauce
anymore, they'll get correct behavior too.
* And if I'm right in my hunch, behavior will be correct for the "module
docs" mode as well as the "reference" mode. If I'm wrong, there are some rare
users who will get a surprise, but it won't be a huge one.
* If they're doing it on an arbitrary agent, they're doing it wrong.
* Docs team's use case remains idiosyncratic, and that's fine, we'll just blank
out the libdir on the command line.
Does that sound right? Also I may be overthinking this, as we're probably the
only ones who use "reference" mode. :/
----------------------------------------
Bug #17156: Regression: Can't restrict the plugins loaded by puppet doc with
--modulepath in 3.0.1
https://projects.puppetlabs.com/issues/17156#change-74996
Author: Nick Fagerlund
Status: Accepted
Priority: Normal
Assignee:
Category: settings
Target version: 3.x
Affected Puppet version: 3.0.1
Keywords: regression settings
Branch:
The docs team uses `puppet doc --reference` to generate certain docs for the
site, and we have to use `--modulepath /tmp/nothing` or something to exclude
non-core resource types and functions from our personal modules. This worked
through 3.0.0 and broke in 3.0.1.
The changed behavior:
* In 3.0.0, puppet doc would ONLY load plugins from the modulepath; the
contents of the agent's libdir had no effect, and changing the modulepath
swapped out the entire set of plugins available.
* In 3.0.1, puppet doc loads plugins from both the modulepath AND the libdir.
So if puppet agent has ever run, puppet doc will keep loading plugins until you
delete the libdir.
Git bisect tracks the change to commit:144bb76a7e825a221fd1cb5a20728c8cf5c03264
-- "(#16637) Fix default confdir and vardir with puppet master as normal user."
The command to test this with is `puppet doc --reference function --modulepath
/tmp/nothing` -- make sure you have something like puppetlabs-stdlib in your
modulepath when testing, so that the function reference gets nice and messy.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.