clean documentation

README.md

@@ -1,8 +1,7 @@
 # The Fediversity project
 
 This repository contains all the code and code-related files having to do with
-[the Fediversity project](https://fediversity.eu/), with the notable exception
+[the Fediversity project](https://fediversity.eu/).
-of [NixOps4 that is hosted on GitHub](https://github.com/nixops4/nixops4).
 
 ## Goals
 
@@ -81,27 +80,15 @@ Not everyone has the expertise and time to run their own server.
   The software includes technical configuration that links software components.
   Most user-facing configuration remains untouched by the deployment process.
 
-  > Example: NixOps4 is used to deploy [Pixelfed](https://pixelfed.org).
+  > Example: OpenTofu is used to deploy [Pixelfed](https://pixelfed.org).
 
 - Migrate
 
   Move service configurations and user data to a different hosting provider.
 
-- [NixOps4](https://github.com/nixops4/nixops4)
+- [OpenTofu](https://opentofu.org/)
 
-  A tool for deploying and managing resources through the Nix language.
+  An infrastructure-as-code tool, and open-source (MPL 2.0) fork of Terraform.
-  NixOps4 development is supported by the Fediversity project
-
-- Resource
-
-  A [resource for NixOps4](https://nixops.dev/manual/development/concept/resource.html) is any external entity that can be declared with NixOps4 expressions and manipulated with NixOps4, such as a virtual machine, an active NixOS configuration, a DNS entry, or customer database.
-
-- Resource provider
-
-  A resource provider for NixOps4 is an executable that communicates between a resource and NixOps4 using a standardised protocol, allowing [CRUD operations](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) on the resources to be performed by NixOps4.
-  Refer to the [NixOps4 manual](https://nixops.dev/manual/development/resource-provider/index.html) for details.
-
-  > Example: We need a resource provider for obtaining deployment secrets from a database.
 
 ## Development
 
@@ -118,9 +105,6 @@ Contact the project team if you have questions or suggestions, or if you're inte
 Most of the directories in this repository have their own README going into more
 details as to what they are for. As an overview:
 
-- [`deployment/`](./deployment) contains work to generate a full Fediversity
-  deployment from a minimal configuration.
-
 - [`infra/`](./infra) contains the configurations for the various VMs that are
   in production for the project, for instance the Git instances or the Wiki, as
   well as means to provision and set up new ones.
@@ -128,14 +112,8 @@ details as to what they are for. As an overview:
 - [`keys/`](./keys) contains the public keys of the contributors to this project
   as well as the systems that we administrate.
 
-- [`matrix/`](./matrix) contains everything having to do with setting up a
-  fully-featured Matrix server.
-
 - [`secrets/`](./secrets) contains the secrets that need to get injected into
   machine configurations.
 
 - [`services/`](./services) contains our effort to make Fediverse applications
   work seemlessly together in our specific setting.
-
-- [`website/`](./website) contains the framework and the content of [the
-  Fediversity website](https://fediversity.eu/)

infra/README.md

@@ -7,7 +7,7 @@ infrastructure.
 
 NOTE[Niols]: This is very manual and clunky. Two things will happen. In the near
 future, I will improve the provisioning script to make this a bit less clunky.
-In the far future, NixOps4 will be able to communicate with Proxmox directly and
+In the future, orchestration will be able to communicate with Proxmox directly and
 everything will become much cleaner.
 
 1. Choose names for your VMs. It is recommended to choose `fediXXX`, with `XXX`
@@ -15,8 +15,7 @@ everything will become much cleaner.
 
 2. Add a basic configuration for the machine. These typically go in
    `infra/machines/<name>/default.nix`. You can look at other `fediXXX` VMs to
-   find inspiration. You probably do not need a `nixos.module` option at this
+   find inspiration.
-   point.
 
 2. Add a file for each of those VM's public keys, eg.
    ```
@@ -59,40 +58,6 @@ everything will become much cleaner.
    FIXME: Figure out why the full configuration isn't on the machine at this
    point and fix it.
 
-## Updating existing VM configurations
-
-Their configuration can be updated via NixOps4. Run
-
-```sh
-nixops4 deployments list
-```
-
-to see the available deployments.
-This should be done from the root of the repository,
-otherwise NixOps4 will fail with something like:
-
-```
-    nixops4 error: evaluation: error:
-           … while calling the 'getFlake' builtin
-
-           error: path '/nix/store/05nn7krhvi8wkcyl6bsysznlv60g5rrf-source/flake.nix' does not exist, evaluation: error:
-           … while calling the 'getFlake' builtin
-
-           error: path '/nix/store/05nn7krhvi8wkcyl6bsysznlv60g5rrf-source/flake.nix' does not exist
-```
-
-Then, given a deployment (eg. `fedi200`), run
-
-```sh
-nixops4 apply <deployment>
-```
-
-Alternatively, to run the `default` deployment, which contains all the VMs, run
-
-```sh
-nixops4 apply
-```
-
 ## Removing an existing VM
 
 See `infra/proxmox-remove.sh --help`.

infra/common/options.nix

@@ -93,7 +93,7 @@ in
         description = ''
           The IP address of the machine, version 4. It will be injected as a
           value in `networking.interfaces.eth0`, but it will also be used to
-          communicate with the machine via NixOps4.
+          communicate with the machine.
         '';
       };
 
@@ -118,7 +118,7 @@ in
         description = ''
           The IP address of the machine, version 6. It will be injected as a
           value in `networking.interfaces.eth0`, but it will also be used to
-          communicate with the machine via NixOps4.
+          communicate with the machine.
         '';
       };
 
@@ -141,7 +141,7 @@ in
     hostPublicKey = mkOption {
       description = ''
         The ed25519 host public key of the machine. It is used to filter Age
-        secrets and only keep the relevant ones, and to feed to NixOps4.
+        secrets and only keep the relevant ones, and to feed to TF.
       '';
     };
 

keys/README.md

@@ -14,7 +14,7 @@ overwrite a secret without knowing its contents.)
 In infra management, the systems' keys are used for security reasons; they
 identify the machine that we are talking to. The contributor keys are used to
 give access to the `root` user on these machines, which allows, among other
-things, to deploy their configurations with NixOps4.
+things, to deploy their configurations.
 
 ## Adding a contributor
 

launch/README.md

@@ -22,6 +22,8 @@ then to initialize, or after updating pins or TF providers:
 setup
 ```
 
+then, one can use the `tofu` CLI.
+
 ## implementing
 
 proper documentation TODO.

launch/garage.nix

@@ -4,7 +4,7 @@ let
   ## and will end up in the Nix store. We don't care as they are only ever
   ## used for testing anyway.
   ##
-  ## FIXME: Generate and store in NixOps4's state.
+  ## FIXME: Generate and store in state.
   mastodonS3KeyConfig =
     { pkgs, ... }:
     {

launch/mastodon.nix

@@ -12,6 +12,6 @@ in
     mastodon = mastodonS3KeyConfig { inherit pkgs; } // {
       enable = true;
     };
-    temp.cores = 1; # FIXME: should come from NixOps4 eventually
+    temp.cores = 1; # FIXME: should come from TF eventually
   };
 }

launch/peertube.nix

@@ -13,7 +13,7 @@ in
       enable = true;
       ## NOTE: Only ever used for testing anyway.
       ##
-      ## FIXME: Generate and store in NixOps4's state.
+      ## FIXME: Generate and store in state.
       secretsFile = pkgs.writeText "secret" "574e093907d1157ac0f8e760a6deb1035402003af5763135bae9cbd6abe32b24";
     };
   };

panel/src/panel/settings.py

@@ -241,6 +241,6 @@ if user_settings_file is not None:
 
 # PATH to expose to launch button
 bin_path=env['BIN_PATH']
-# path of the root flake to trigger nixops from, see #94.
+# path of the root flake to deploy from
 # to deploy this should be specified, for dev just use a relative path.
 repo_dir = env["REPO_DIR"]

secrets/README.md

@@ -22,7 +22,7 @@ As an example, let us add a secret in a file “cheeses” whose content should
    extension); this will open your `$EDITOR` ; enter “best ones come
    unpasteurised”, save and close.
 
-3. If you are doing something flake-related such as NixOps4, remember to commit
+3. If you are doing something flake-related, remember to commit
    or at least stage the secret.
 
 4. In the machine's configuration, load our `ageSecrets` NixOS module, declare the machine's host key and start using your secrets, eg.:

services/fediversity/default.nix

@@ -31,7 +31,7 @@ in
         type = types.submodule {
           options = {
             cores = mkOption {
-              description = "number of cores; should be obtained from NixOps4";
+              description = "number of cores; should be obtained from TF";
               type = types.int;
             };
 

services/fediversity/peertube/options.nix

@@ -20,7 +20,7 @@ in
         description = ''
           Internal option — change at your own risk
 
-          FIXME: should it be provided by NixOps4?
+          FIXME: should it be provided by TF?
           or maybe we should just ask for a main secret from which to derive all the others?
         '';
       };