From 467aa42c76948f516bda7c2d86bb6b12470df376 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Charaoui?= <jerome@riseup.net>
Date: Mon, 16 Dec 2024 09:34:41 -0500
Subject: [PATCH] howto/puppet: update proposed steps
this updates the puppet control repo proposal to account for the fact
that the repository would track an environment as opposed to /etc/puppet
altogether
it also adds to the proposal renaming hiera -> data, site-modules -> site and
adding "legacy" to the environment modulepath which would contain all
modules which still need to be either published as a public module or
transformed into a profile
note that while I've tried to retain consistency with "step 0" of
publishing our puppet code, I don't think we should maintain this goal,
let alone keep it as the very first step before everything else
---
howto/puppet.md | 89 +++++++++++++++++++++++--------------------------
1 file changed, 41 insertions(+), 48 deletions(-)
diff --git a/howto/puppet.md b/howto/puppet.md
index c467c79d..f01d05bf 100644
--- a/howto/puppet.md
+++ b/howto/puppet.md
@@ -2045,7 +2045,6 @@ This is the data that needs to be moved into Trocla at the time of writing:
* `modules/postfix/files/virtual` - email addresses
* `modules/postfix/files/access-1-sender-reject` and related - email addresses
* sudoers configurations?
- * secrets in /etc/puppet (hopefully not in git, but just in case)
A full audit should be redone before this is completed.
@@ -2058,28 +2057,25 @@ which chain-loads all the other modules. This implies turning all our
public consumption) "outside", into public repositories (see also
[issue 29387: publish our puppet repository](https://gitlab.torproject.org/tpo/tpa/team/-/issues/29387)).
-Note that the control repository *could* also be public: we could
-simply have the private data inside of Hiera or some other private
-repository.
+Note that the control repository *could* also be public: we could simply have
+all the private data inside of Trocla or some other private repository.
-The control repository concept is specific to the proprietary version
-of Puppet (Puppet Enterprise or PE) but its logic should be usable
-with the open source Puppet release as well.
+The control repository concept originates from the proprietary version
+of Puppet (Puppet Enterprise or PE) but its logic is applicable to the
+open source Puppet release as well.
### Get rid of 3rdparty
The control repo's core configuration file is the `Puppetfile`. We
-already use a Puppetfile, but only to manage modules inside of the
-`3rdparty` directory. Now it would manage *all* modules, or, more
-specifically, `3rdparty` would become the default `modules` directory
-which would, incidentally, encourage us to upstream our modules and
-publish them to the world.
-
-Our current `modules` directory would move into `site-modules`, which
-is the designated location for "roles, profiles, and custom
-modules". This has been suggested before in [issue 29387: publish our
-puppet repository](https://gitlab.torproject.org/tpo/tpa/team/-/issues/29387)) and is important for the `Puppetfile` to do its
-job.
+already use a Puppetfile to manage modules inside of the `3rdparty`
+directory.
+
+Our current `modules/` directory would be split into `site/`, which
+is the designated location for roles and profiles, and `legacy/`, which
+would host private custom modules, with the goal of getting rid of `legacy/`
+altogether by either publishing our custom modules and integrating them into
+the `Puppetfile` or transforming them into a new profile class in
+`site/profile/`.
In other words, this is the checklist:
@@ -2087,36 +2083,33 @@ In other words, this is the checklist:
requires creating `roles` for each machine (more or less) --
effectively done as far as this issue is concerned
* [ ] sanitize repository (tpo/tpa/team#29387)
- * [ ] move `3rdparty` modules into `modules/`
-
-Once this is done, the final picture will look like this in `/etc/puppet`:
-
- * `hiera/` - private data. `machine -> role` assignments, secret
- stuff like the alias file, machine location, price and other
- similar metadata and details (see also legacy/trac#29816)
-
- * `modules/` - equivalent of the current `3rdparty/` directory: fully
- public, reusable code that's aimed at collaboration. mostly code
- from the Puppet forge or our own repository if no equivalent there
-
- * `site-modules/profiles/` - magic sauce on top of 3rd party
- `modules/`, already created a few `modules/profiles/` for grafana
- and prometheus, the profiles configure official 3rd party classes
- with our site-specific criteria
-
- * `site-modules/roles/` - abstract classes that regroup a few
- profiles. for example `roles::monitoring` could currently include
- `profiles::prometheus::server` and `profiles::grafana` as an implementation
-
- * `site-modules/MODULE/` - remaining custom modules that still need
- to be published (by moving in their own repository and `modules/`
- or by replacing with an existing module in `modules/`
-
-This could all be done in the current repository, without creating a
-new clean history one, but it would prepare us for that final
-step. And that step would simply be to move `modules/`, `profiles/`,
-and `roles/` into a public repository, while keeping `hiera/` private
-in its own repository.
+ * [ ] rename `hiera/` to `data/`
+ * [ ] add `site/` and `legacy/` to modulepaths environment config
+ * [ ] move `modules/profile/` and `modules/role/` modules into `site/`
+ * [ ] move remaining modules in `modules/` into `legacy/`
+ * [ ] move `3rdparty/*` into environment root
+
+Once this is done, our Puppet environment would look like this:
+
+ * `data/` - configuration data for profiles and modules
+
+ * `modules/` - equivalent of the current `3rdparty/modules/` directory: fully
+ public, reusable code that's aimed at collaboration, mostly code from the
+ Puppet forge or our own repository if no equivalent there
+
+ * `site/profile/` - "magic sauce" on top of 3rd party `modules/` to
+ configure 3rd party modules according to our site-specific requirements
+
+ * `site/role/` - abstract classes that assemble several profiles to define
+ a logical role for any given machine in our infrastructure
+
+ * `legacy/` - remaining custom modules that still need to be either published
+ and moved to their own repository in `modules/`, or replaced with an existing
+ 3rd party module (eg. from voxpupuli)
+
+Although the module paths would be rearranged, no class names would be changed
+as a result of this, such that no changes would be required of the actual puppet
+code.
### Deploy with g10k
--
GitLab