= Where to Put Community Modules? =
== Backstory ==
Starting with Puppet 6.0 some formally core puppet types have been moved into community maintained modules, namely `nagios_core` & `mailalias_core`, both of which we use. I opened a [[https://gerrit.wikimedia.org/r/c/operations/puppet/+/763611|patch]] to propose adding them to our repository. @jbond & @MoritzMuehlenhoff raised important concerns about how we want to handle community modules.
== Question ==
We have two primary types of puppet modules in our repository, Community developed modules and In House developed modules. Community modules are those that we import into or repository, but are developed by a community outside of the foundation, e.g. stdlib, concat, lvm, etc. In House developed modules are those used solely by the foundation and developed in our puppet repository, e.g. ganeti, zookeeper, etc. At preset we co-mingle both types of modules into our single puppet repository under the `./modules` directory. Should we continue to do so?
== Options ==
=== Vendor modules in our repository under `./modules` ===
This is what we presently do.
==== Advantages ====
* No packaging required, easy to add new modules
* Easy to patch
* Easy to find any module
* Easy `git grepping`
* Supports a masterless mode of applying
==== Disadvantages ====
* Hard to distinguish between Community & In House modules
* Hard to see git history of Community modules
=== Vendor modules in our repository under `./vendor/modules` ===
Similar to what we presently do, but uses a directory to separate the two types.
==== Advantages ====
* Easy to distinguish between Community & In House modules
* No packaging required, easy to add new modules
* Easy to patch
* Easy `git grepping`
* Supports a masterless mode of applying
==== Disadvantages ====
* Hard to see git history of Community modules
* Slightly harder to find where a module lives
=== Use git submodules under `./vendor/modules` ===
Rather than dumping code from Community modules, use a git submodule to add the Community repository inside our repository.
==== Advantages ====
* Easy to see git history of Community modules
* Easy to distinguish between Community & In House modules
* No packaging required, easy to add new modules
* Easy to fork
* Supports a masterless mode of applying
==== Disadvantages ====
* Slightly harder `git grepping`, `git grep --recurse-submodules 'butter'`
* Slightly harder to find where a module lives
=== Package Community modules as Debian packages ===
Along with the puppet agent we would package Community modules as Debian Packages and install them along with the puppet agent on a host.
==== Advantages ====
* Easy to distinguish between Community & In House modules
==== Disadvantages ====
* Hard `git grepping`
* Hard to see git history of Community modules
* Hard to patch, would require a fork, submit pull request, get approval, repackage.
* Does not support a masterless mode of applying
* Additional maintenance burden of maintaining Debian packages
* Hard to find any module
=== Use a Puppetfile, with R10k ===
Instead of storing modules in our repository we would have a separate "control repo" which defines all our modules in a [[https://github.com/puppetlabs/r10k/blob/main/doc/puppetfile.mkd|Puppetfile]].
==== Advantages ====
* Easy to distinguish between Community & In House modules
* Easy to fork
==== Disadvantages ====
* Would require a significant time investment to migrate all of modules into separate repositories.
* Hard `git grepping`
* Hard to see git history of Community modules
* Does not support a masterless mode of applying
=== Option X? ===