specifies classes in the data model, raising these to from `_class`
model attributes to `subModuleWith`'s `class` parameter where possible.
note: resource policy has remained as to use `deferredModuleWith`
(rather than `submoduleWith`) to ensure evaluation will go thru.
Closes#103
At last, a fully fledged data model for what Fediversity really is and does. This comes with a test that exercises a very simple but functionally complete arrangement with all ingredients fo the business logic: a dummy resource (login shell), a dummy application (`hello`, which needs a shell to live in), a dummy environment (a single NixOS VM that allows for one, the operator's, login shell), and a deployment of that environment given a dummy configuration (that enables `hello`).
The next step will be to lift this purely evaluation-level test into a VM test which verifies that the resulting VM indeed has `hello` deployed to the operator's user account.
Caveats:
- The exact naming has a bit of room for improvement, and may have diverged from the design document
- The test is not as pedantically type safe as it could be, since we simply use `types.raw` for resources such as NixOS users settings which *could* be more finely delineated
Co-authored-by: Kiara Grouwstra <kiara@procolix.eu>
Co-authored-by: kiara Grouwstra <kiara@procolix.eu>
Reviewed-on: Fediversity/Fediversity#481
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-committed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Now that we won't depend on the flake.nix anymore, we won't depend on all the flake-part.nix files (necessary to evaluate flake.nix) and all the files they depend on etc., so the Nix dependencies of the tests will be drastically reduced, and I will be able to leverage that by introducing a more subtle src. This will make the test not need to re-run if only things outside that reduced src changed (and the previous run is in the Nix store).
Reviewed-on: Fediversity/Fediversity#450
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Reviewed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
Co-committed-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
This PR builds on top of #447 and #448. Since these might be rejected, there will be some changes needed for this PR as well. Let's see how the discussions go in #447.
In the meantime, @fricklerhandwerk, would you mind (in)validating the core idea of this PR? You only need to look at 7cf43c4041, really.
Reviewed-on: Fediversity/Fediversity#449
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Reviewed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
Co-committed-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
This PR builds on top of #447 and will be subject to the same discussion. Let's discuss there whether it makes sense to get rid of the `flake-parts` and `git-hooks` flake inputs.
Reviewed-on: Fediversity/Fediversity#448
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
Co-committed-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
The goal is to contain the “`mkFlake` hack” to a file that we can heavily document but otherwise ignore. This also will allow me to reuse it in the “flake under test” of the deployment tests.
Reviewed-on: Fediversity/Fediversity#447
Reviewed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
Co-committed-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
closes#93.
note that this includes classes:
- `nixos`
- `nixosTest`
- `nixops4Resource`
- `nixops4Deployment`
.. and my (made-up, as per the [docs](https://ryantm.github.io/nixpkgs/module-system/module-system/#module-system-lib-evalModules-param-class)):
- `nix-unit`
- `package`
.. while i did not manage to cover:
- service tests, given `pkgs.nixosTest` seemed to not actually like `_class = "nixosTest"` (?!)
... nor #93's mentioned destructured arguments for that matter, as per Fediversity/Fediversity#93 (comment) - let me know if that is still desired as well.
Reviewed-on: Fediversity/Fediversity#398
Reviewed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Kiara Grouwstra <kiara@procolix.eu>
Co-committed-by: Kiara Grouwstra <kiara@procolix.eu>
Closes#277
Same as #329 but where we run the FediPanel and interact with it via a browser
instead of running NixOps4 directly.
Reviewed-on: Fediversity/Fediversity#361
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Reviewed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
Co-committed-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
The tests still work because we manually write the deployer's public key in `/root/.ssh/authorized_keys` on the target machines. In itself, however, the configuration that we push does not allow the deployer to push anything on the target machines.
Context: Fediversity/Fediversity#361 (comment)
Reviewed-on: Fediversity/Fediversity#385
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
Co-committed-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
@Niols the sheer amount of hassle and noise indicates that it may be better to first split out a `flake.nix` just for the tests. And all this clutter doesn't even explain yet *why* we thought it needs to be there.
closes#279.
Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
Reviewed-on: Fediversity/Fediversity#374
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-committed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Closes Fediversity/Fediversity#276
This PR adds a CLI deployment test. It builds on top of Fediversity/Fediversity#323. This test features a deployer node and four target nodes. The deployer node runs `nixops4 apply` on a deployment built with our actual code in `deployment/default.nix`, which pushes onto the four target machines combinations of Garage/Mastodon/Peertube/Pixelfed depending on a JSON payload. We check that the expected services are indeed deployed on the machines. Getting there involved reworking the existing basic test to extract common patterns, and adding support for ACME certificates negotiation inside the NixOS test.
What works:
- deployer successfully runs `nixops4 apply` with various payloads
- target machines indeed get the right services pushed onto them and removed
- services on target machines successfully negotiate ACME certificates
What does not work: the services themselves depend a lot on DNS and that is not taken care of at all, so they are probably very broken. Still, this is a good milestone.
Test it yourself by running `nix build .#checks.x86_64-linux.deployment-basic -vL` and `nix build .#checks.x86_64-linux.deployment-cli -vL`. On the very beefy machine that I am using, the basic test runs in ~4 minutes and the CLI test in ~17 minutes. We know from Fediversity/Fediversity#323 that the basic test runs in ~12 minutes on the CI runner, so maybe about an hour for the CLI test?
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Reviewed-on: Fediversity/Fediversity#329
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Reviewed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
Co-committed-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
this shows a proof of concept for generating Django forms from NixOS modules
note that the form behavior is still rather clumsy and doesn't exactly map to the module semantics:
- since forms can only be sent wholesale, empty form fields will show up as empty strings
and break validation without additional cleanup (not done here)
- it's not possible to faithfully translate `type = submodule { /* ... */}; default = {};`, since the default
is translated to an empty dict `{}`. this is because the JSON schema converter does not preserve type information.
this can be added by making it use `$defs` [1], but that would likely amount to half a rewrite
- there's a glitch in enum default values that needs to be fixed in `datamodel-code-generator` [0]
[0]: dd44480359/src/datamodel_code_generator/parser/base.py (L1015)
[1]: https://json-schema.org/understanding-json-schema/structuring#defs
a generated file will be placed into the source (by the development shell and the package respectively)
that declares Pydantic types from which to render the form. it looks something like this:
```python
from __future__ import annotations
from enum import Enum
from typing import Optional
from pydantic import BaseModel, Extra, Field
from drf_pydantic import BaseModel
class Domain(Enum):
fediversity_net = 'fediversity.net'
# ...
class Model(BaseModel):
class Config:
extra = Extra.forbid
domain: Optional[Domain] = Field(
'fediversity.net',
description='Apex domain under which the services will be deployed.\n',
)
# ...
```
This PR adds a basic deployment test to the repository. This test will, in a NixOS test, run a deployer VM and a target VM, and check that we manage to run `nixops4 apply` on the deployer VM to change things on the target VM. The ideas are all @roberth's and this test has been extremely heavily inspired by https://github.com/nixops4/nixops4-nixos/blob/main/test/default/nixosTest.nix.
Reviewed-on: Fediversity/Fediversity#323
Reviewed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
Co-committed-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
this change is a no-op (it merely indents the option definitions by one,
by setting `config` explicitly) and prepares an addition of option
declarations that would otherwise be lost in the huge diff.
Reviewed-on: Fediversity/Fediversity#315
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
