2024-06-15 11:41:51 +00:00
|
|
|
# Inventory
|
|
|
|
|
2024-06-20 16:52:34 +00:00
|
|
|
The inventory is our concept for distributed services. Users can configure multiple machines with minimal effort.
|
|
|
|
|
|
|
|
- The inventory acts as a declarative source of truth for all machine configurations.
|
2024-06-21 14:45:38 +00:00
|
|
|
- Users can easily add or remove machines to/from services.
|
2024-06-20 16:52:34 +00:00
|
|
|
- Ensures that all machines and services are configured consistently, across multiple nixosConfigs.
|
|
|
|
- Defaults and predefined roles in our modules minimizes the need for manual configuration.
|
|
|
|
|
2024-06-22 19:31:01 +00:00
|
|
|
Open questions:
|
2024-06-20 16:36:26 +00:00
|
|
|
|
2024-06-22 19:31:01 +00:00
|
|
|
- [ ] How do we set default role, description and other metadata?
|
|
|
|
- It must be accessible from Python.
|
|
|
|
- It must set the value in the module system.
|
2024-06-20 16:36:26 +00:00
|
|
|
|
2024-06-22 19:31:01 +00:00
|
|
|
- [ ] Inventory might use assertions. Should each machine inherit the inventory assertions ?
|
2024-06-20 16:36:26 +00:00
|
|
|
|
2024-06-22 19:31:01 +00:00
|
|
|
- [ ] Is the service config interface the same as the module config interface ?
|
2024-06-20 16:36:26 +00:00
|
|
|
|
2024-06-22 19:31:01 +00:00
|
|
|
- [ ] As a user do I want to see borgbackup as the high level category?
|
2024-06-20 16:36:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
Architecture
|
|
|
|
|
|
|
|
```
|
2024-06-20 16:52:34 +00:00
|
|
|
nixosConfig < machine_module < inventory
|
2024-06-20 16:36:26 +00:00
|
|
|
---------------------------------------------
|
2024-06-21 15:00:44 +00:00
|
|
|
nixos < borgbackup <- inventory <-> UI
|
2024-06-20 16:36:26 +00:00
|
|
|
|
|
|
|
creates the config Maps from high level services to the borgbackup clan module
|
2024-06-21 15:00:44 +00:00
|
|
|
for ONE machine Inventory is completely serializable.
|
|
|
|
UI can interact with the inventory to define machines, and services
|
|
|
|
Defining Users is out of scope for the first prototype.
|
2024-06-20 16:36:26 +00:00
|
|
|
```
|
|
|
|
|
2024-06-22 19:31:01 +00:00
|
|
|
## Provides a specification for the inventory
|
2024-06-15 11:41:51 +00:00
|
|
|
|
|
|
|
It is used for design phase and as validation helper.
|
|
|
|
|
|
|
|
> Cue is less verbose and easier to understand and maintain than json-schema.
|
|
|
|
> Json-schema, if needed can be easily generated on-the fly.
|
|
|
|
|
|
|
|
## Checking validity
|
|
|
|
|
|
|
|
Directly check a json against the schema
|
|
|
|
|
|
|
|
`cue vet inventory.json root.cue -d '#Root'`
|
|
|
|
|
|
|
|
## Json schema
|
|
|
|
|
|
|
|
Export the json-schema i.e. for usage in python / javascript / nix
|
|
|
|
|
|
|
|
`cue export --out openapi root.cue`
|
|
|
|
|
|
|
|
## Usage
|
|
|
|
|
|
|
|
Comments are rendered as descriptions in the json schema.
|
|
|
|
|
|
|
|
```cue
|
|
|
|
// A name of the clan (primarily shown by the UI)
|
|
|
|
name: string
|
|
|
|
```
|
|
|
|
|
|
|
|
Cue open sets. In the following `foo = {...}` means that the key `foo` can contain any arbitrary json object.
|
|
|
|
|
|
|
|
```cue
|
|
|
|
foo: { ... }
|
|
|
|
```
|
|
|
|
|
|
|
|
Cue dynamic keys.
|
|
|
|
|
|
|
|
```cue
|
|
|
|
[string]: {
|
|
|
|
attr: string
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
This is the schema of
|
|
|
|
|
|
|
|
```json
|
|
|
|
{
|
|
|
|
"a": {
|
|
|
|
"attr": "foo"
|
|
|
|
},
|
|
|
|
"b": {
|
|
|
|
"attr": "bar"
|
|
|
|
}
|
|
|
|
// ... Indefinitely more dynamic keys of type "string"
|
|
|
|
}
|
|
|
|
```
|