In Puppet 3.0.0 we tried to get a fix in for #7316, but, after many valiant
efforts, that did not come to pass. For Puppet 3.1.0 we are trying again.
The problem boils down to the issue that when the Puppet::Util::CommandLine
code tries to find the ruby code for the subcommand to execute, it hasn't
yet figured out the modulepath. Without knowing the modulepath, we can't
find applications or faces that are in modules. The reason it doesn't know
the modulepath is because the modulepath is tied to the section of the
configuration file that it should use, which is only determined by the run
mode. The run mode is only known *after* we have loaded the application.
And therein lies the problem:
In order to figure out where to look for an application to load we need
to load the
application so that it can tell us where we should look for the
application to load.
Josh Cooper and I (and previously Jeff McCune) have been combing through
the code and redmine and trying to piece together all of the ramifications
of this problem (you can see the result of that from the list of related
issues). The issue and its relations show up in a lot of places
(environments for instance) and in several different guises (loading
utility code in a module, being able to initialize puppet for use as a
library). Each time we thought we understood what was going on we came up
with a proposed solution, but as soon as we learned a bit more, that
solution fell apart.
We've documented most of that at
https://docs.google.com/document/d/1hNky74PkNgNxTkfxtoz2if6gAYrrPhudVXJSZCsxSMo/edit
At the moment Proposal 4 is looking the most promising. It is to pretty
much undo the changes for #2935 (which added run_mode) and change to a
configuration system such that each subcommand has a section in the
configuration file. This means that we can statically know what part of the
configuration file to use for any given subcommand without first having to
load any code first.
I've hacked (and hacked is really the right word) together some changes
that start doing this on a branch in my repo.
https://github.com/zaphod42/puppet/tree/spike/master/subcommands-as-conf-sections
Any changes around this could have wide ranging impact and so we really
need to make sure we get this right. Can anyone think of what doing this
would horribly break? Other solutions that would achieve similar results,
but might work better?
Andy
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" 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-dev?hl=en.