I would ask that you only vendor items that are super generic and that you namespace them such that they won't interfere with people already written codebases.
The following seem relatively safe since they've been in use for quite some time: - stdlib - archive (maybe) - inifile - powershell (maybe) However, there are a LOT of sudo, etc... implementations which mean that you're going to pretty much break everyone's environments out of the box and cause a great number of headaches. Furthermore, what happens when I want the next version of 'stdlib' with the new shiny but you've baked in a version that now makes me work around everything? If you want a 'new user pack', make it just that, an extra package that I can install that will drop a bunch of vendored modules somewhere and provide me with instructions on setting it up. I do not feel that putting this in 'puppet-agent' itself is a good idea *at all*, particularly considering that we still can't build puppet-agent from source to override any shenanigans that may arise from these good intentions. Thanks, Trevor On Thu, Apr 26, 2018 at 5:49 PM, Josh Cooper <j...@puppet.com> wrote: > 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 > <https://groups.google.com/d/msgid/puppet-dev/CA%2Bu97unFNeUF_5oxumMFTER5hkgR_45FSPcKuE6ogo-9KCjnLw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoX49%3D4b04dEpZD4rud%2BUHL5unQDUmz%3DFVE83LGavtfmwg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
