kiara/fedi-goals
1
0
Fork 1
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

tweak project proposal #1

Open
kiara wants to merge 95 commits from rewrite into main
pull from: rewrite
merge into: kiara:main
Conversation 0 Commits 95 Files changed 6 +9 -19
1 changed files with 9 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files
Showing only changes of commit 344dce00a3 - Show all commits

28
architecture.md
View file

@ -58,32 +58,22 @@
Move service configurations and deployments (including user data) from one hosting provider to another.
- Runtime backend
- Run-time backend
A type of digital environment one can run operating systems such as NixOS on, e.g. bare-metal, a hypervisor, or a container runtime.
A type of digital environment one can run operating systems such as NixOS on, e.g. bare-metal, a hypervisor, or a container run-time.
- Runtime environment
- Provider
The thing a deployment runs on, an interface against which the deployment is working. See runtime backend.
An interface against which we deploy to a run-time backend.
- Runtime configuration
- Provider configuration
A specification for mapping components of a configuration to the runtime environment, e.g. which services to deploy to which virtual machines, or how to access object storage.
- [NixOps4](https://nixops.dev)
A tool to interact with mutable external resources based on declarations in the [Nix language](https://nix.dev/manual/nix/latest/language/).
A configuration that specifies resources made available to deploy to and how to access these.
- 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.
A resource is any external entity that we need for our set-up
This may include e.g. hypervisors, file systems, DNS entries, VMs or object storage instances.
## Technologies used
@ -145,7 +135,7 @@ For further info on components see the [glossary](#glossary).
This data flow diagram refines how a deployment is obtained from an operator's application configuration and a hosting provider's runtime setup.
An **application module** specifies operator-facing **application options**, and a **resource mapping** which determines the application's underlying implementation. Application modules can be supplied by external developers, which would curate application modules against that interface.
An **application module** specifies operator-facing **application options**, and a **configuration mapping** which determines the application's underlying implementation. Application modules can be supplied by external developers, which would curate application modules against that interface.
For its runtime setup, a hosting provider has to supply a **resource mapping** that would take their self-declared **provider configuration** (which determines the *available* resources) and the output of an application's resource mapping (which determine resource *requirements*) and produce a **configuration**. This configuration ships with a mechanism to be *deployed* to the infrastructure (which is described by the environment, and features the required resources), where it will accumulate **application state**.