Oh, and you're possibly setting yourself up for SERVER-94 hell if you're not EXTREMELY careful.
On Thu, Apr 26, 2018 at 10:42 PM, Trevor Vaughan <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 >> [email protected] | @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 [email protected]. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/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 -- > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXPt%2BL8sQyHtiDu%3DZOYR91Boeo0WXS8S-BkVOoDeaGrZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
