Some people raised concerns about vendoring modules in the puppet-agent
package[1]. I wanted to provide some more context about the "why", and some
refinements to the "how".
First, new users should be able to download the puppet-agent package and
manage basic resources for the platform they're running on. We don't want
users to download an engine and be forced to assemble a car. Commonly used
modules like stdlib, archive, sudo, inifile, powershell, etc should be part
of the initial experience.
On the other hand, advanced puppet users don't want vendored modules
conflicting with modules they're already managing using r10k,
librarian-puppet, etc. Another way to think about it is, if you're going
through the trouble of specifying your dependencies in a Puppetfile, then
you want the same results no matter which puppet-agent version you're
using. If you start to rely on vendored module magic to satisfy
dependencies, then failures will happen as the puppet-agent package is
updated over time.
It's also important to consider serverless vs server-based deployments.
When running serverless puppet (apply, resource, describe, etc), modules
only need to be installed on the local system. However, for server-based
puppet, modules need to be installed on the server and downloaded to the
agent. In this scenario, an agent's vendored modules are not useful.
We also can't assume that vendored modules on the server are applicable to
the agents you're trying to manage. For example, you may have a RHEL
server, but Windows, OSX, etc agents.
So we have different constraints for new users vs advanced users, and
serverless vs server-based deployments. Is there a solution that makes
Puppet more accessible for new users while not getting in the way for
advanced users?
I'm proposing we add the vendored modules directory to the basemodulepath
with the least precedence. So on *nix, basemodulepath would default to:
/etc/puppetlabs/code/modules:/opt/puppetlabs/puppet/modules:
/opt/puppetlabs/puppet/vendor_modules
On Windows, we'd do something similar by appending $installdir\Puppet
Labs\Puppet\puppet\vendor_modules to the basemodulepath. Note the exact
location depends on the installation directory, typically C:\Program Files.
For serverless puppet, e.g. puppet apply, we would only load modules from
the vendored directory as a last resort. This way if you `puppet module
install puppetlabs-stdlib` you'd always use that version no matter what
version is vendored in the puppet-agent package.
With server-based puppet, the server would also only load from the vendored
directory as a last resort. That way if you installed the module following
the roles and profiles pattern, and set your per-environment:
modulepath=site:modules:$basemodulepath
Then the server would always prefer the per-environment module over the
vendored one.
The server's compiler and fileserver would resolve modules the same way,
since they both call Puppet::Node::Environment#modules. This is important
so that agents always pluginsync the same version of the type (and its
provider) as was used during compilation. And the agent would need to
always prefer its pluginsync libdir over any modules that may be locally
installed (vendored or otherwise).
Finally, if you really don't want to use vendored modules, then you can
override basemodulepath, omitting the "vendored_modules" directory, and
everything will work as it did before.
Josh
[1] https://github.com/puppetlabs/puppet-specifications/pull/106
On Wed, Mar 21, 2018 at 10:14 AM, Josh Cooper <j...@puppet.com> wrote:
> We've been talking about moving non-core types and providers out of the
> puppet repo for many years[1], and we are going to make every effort to
> make that happen for Puppet 6, finally! I've written up a proposal in the
> form of a PR to the puppet-specifications repo[2]. Please take a look and
> comment on the PR.
>
> Thanks!
> Josh
>
> [1] https://groups.google.com/d/msg/puppet-dev/4y9ZvbbkKBs/z1KdGGQyGWkJ
> [2] https://github.com/puppetlabs/puppet-specifications/pull/106
>
--
Josh Cooper | Software Engineer
j...@puppet.com | @coopjn
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CA%2Bu97unFNeUF_5oxumMFTER5hkgR_45FSPcKuE6ogo-9KCjnLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
