on migration, allow reconfiguring monolithic vs distributed #341

New issue

Open

opened 2025-05-27 12:52:57 +02:00 by kiara · 0 comments

kiara commented

2025-05-27 12:52:57 +02:00

Owner

As a Fediversity user,
when I migrate to a different environment,
I want the option to reconfigure whether to use a monolithic vs a distributed setup,
so that the new setup may take into account the capacity of (nodes on) the new environment.

Test

Given I am migrating my Fediversity set-up (#100),
When I follow in-app instructions to reconfigure from a monolithic to a distributed configuration (or vice versa),
Then my new deployment will reflect this desired configuration.

implementation notes

our data model's resource mapping supports pluggable logic on how to allocate resources to set-ups (implementation todo)
c.f.: #322 / #339, both about hard-coding a monolithic setup
moves more from vars (#493) to the orchestrator (#515)
the #494 PR already demonstrated a distributed setup - so tackling this seems about making a monolithic version, then parameterizing to switch between these two
this seems relevant also to port the VM setups to the data model such as to include Garage into the same NixOS configuration
c.f. Trac environments

**As** a Fediversity user, **when** I migrate to a different environment, **I want** the option to reconfigure whether to use a monolithic vs a distributed setup, **so that** the new setup may take into account the capacity of (nodes on) the new environment. ## Test **Given** I am migrating my Fediversity set-up (#100), **When** I follow in-app instructions to reconfigure from a monolithic to a distributed configuration (or vice versa), **Then** my new deployment will reflect this desired configuration. ## implementation notes - our [data model](https://git.fediversity.eu/fediversity/meta/src/branch/main/architecture-docs/architecture.md#configuration-data-flow)'s resource mapping supports pluggable logic on how to allocate resources to set-ups (implementation todo) - c.f.: #322 / #339, both about hard-coding a monolithic setup - moves more from vars (#493) to the orchestrator (#515) - the #494 PR already demonstrated a distributed setup - so tackling this seems about making a monolithic version, then parameterizing to switch between these two - this seems relevant also to port the VM setups to the data model such as to include Garage into the same NixOS configuration - c.f. [Trac environments](https://sandervanderburg.blogspot.com/2011/02/using-nixos-for-declarative-deployment.html)

Rows
Columns