import checklist from team#29387

howto/puppet.md

@@ -1753,9 +1753,10 @@ configuration.
 
 TL;DR:
 
+ 0. publish our repository (tpo/tpa/team#29387)
  1. Use a control repository
- 2. Get rid of 3rdparty
- 3. Deploy with g10k
+ 2. Get rid of `3rdparty`
+ 3. Deploy with `g10k`
  4. Authenticate with checksums
  5. Deploy to branch-specific environments
  6. Rename the default branch "production"
@@ -1772,6 +1773,35 @@ and could be implemented once the new infrastructure stabilizes.
 
 What follows is an explanation and justification of each step.
 
+### Publish our repository
+
+Right now our Puppet repository is private, because there's
+sensitive information in there. The goal of this step is to make sure
+we can safely publish our repository without risking disclosing
+secrets.
+
+Secret data is currently stored in Trocla, and we should keep using it
+for that purpose. That would avoid having to mess around splitting the
+repository in multiple components in the short term.
+
+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.
+
+The actual issues that need to be resolved to close this ticket are
+really just 1 and 2, however: it just means we would need to push to
+two repositories to get our code public. So as a temporary measure, we
+would push the public repositories twice: once to the public git
+repository (ie. here) and once to the private one. Eventually, we
+would push directly with Puppet which, with access keys, would push
+public repositories here. But that's not essential to close this
+ticket, which is just about publishing our darn source code.
+
 ### Use a control repository
 
 The base of the infrastructure is a [control-repo](https://puppet.com/docs/pe/latest/control_repo.html) ([example](https://github.com/puppetlabs/control-repo),
@@ -1804,6 +1834,48 @@ 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.
 
+In other words, this is the checklist:
+
+ * [x] convert everything to hiera (#30020) - this requires creating `roles` for each machine (more or less) -- effectively done as far as this issue is concerned
+ * [ ] move current `modules/` into `site-modules/` and audit for private data
+ * [ ] move any private data into `hiera/`, currently known private data:
+   * `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)
+ * [ ] move `3rdparty` modules into `modules/`
+ * [ ] publish everything but `hiera/` as a new (secret) repository
+
+Once this is done, the final picture will look like this in `/etc/puppet`:
+
+ * `hiera/` - private data. `machine -> role` assignements, 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::nagiosmaster`, `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.
+
 ### Deploy with g10k
 
 It seems clear that everyone is converging over the use of a