Verified Commit 8ebb1c27 authored by anarcat's avatar anarcat 💥
Browse files

TPA-RFC-77: suggestion of "next steps" 

I feel we're missing a big thing here, which is "what do we end up
with at the end here" and "how do we move forward". So here's my
modest proposal of how we could continue the work after the work in
the proposal is completed.

See: team#41948
parent 3c1bb4cd

policy/tpa-rfc-77-puppet-merge.md

+24 −0
Original line number Diff line number Diff line
@@ -105,6 +105,30 @@ TODO: the last two feel like "non-goals" above.. I wonder if it's 
worth just removing those? In any case, they feel oddly vague and out

of place.



## Next steps



From here on, there's a single code base on a single Puppet server,

and nodes from both fleets (Tails and TPA) use the same environment.



The code base is not, however, fully merged just yet, of course. A

possible way forward to merge services might be like this:



- There's a Hiera parameter that determines whether a node is "Tails"

  or "TPA", let's call it the "flag"

- The "flag" determines which base profile (`profile::tails` or

  `profile::tpa` maybe?) gets included

- The profiles start fully divergent: they include different profiles

  and classes, but can also have the same classes included (say

  `unattended_upgrades`, assuming it's used by both)

- To "merge" a service, a class existing in one profile (say

  `profile::prometheus` from `profile::tpa`) is progressively added to

  all nodes on the other side, and eventually to the other profile

  (say `profile::tails`)



So while we don't have a detailed step-by-step plan to merge all

services, the above should give us general guidelines to merge

services on a need-to basis, and progress in the merge roadmap.



# Costs



TODO: try to break down costs of each of the above steps, to get a