Hosting providers can update their operators' deployments #159

New issue

Open

opened 2025-02-19 17:10:17 +01:00 by Niols · 1 comment

Niols commented

2025-02-19 17:10:17 +01:00

Owner

As a hosting provider,
I want to be able to update my operators' deployment when needed,
so that they may enjoy security and feature updates.

Test:

Given I have global configuration updates (e.g. rekeying, security updates, Fediversity update) that affect all operators,
When I request a re-deployment of all my operators' configurations,
Then, each operator is notified and provided with a means to specify a maintenance shutdown period during which their configuration will be automatically re-deployed.

notes

breaking changes to operator-facing configuration may be handled by any of:

migrating state / mappings (#629)
user action (aided by #214)

implementation notes

handle application version updates in service scripts
by application (also see our apps sheet's upgrade column)

**As** a hosting provider, **I want** to be able to update my operators' deployment when needed, **so that** they may enjoy security and feature updates. ### Test: **Given** I have global configuration updates (e.g. rekeying, security updates, Fediversity update) that affect all operators, **When** I request a re-deployment of all my operators' configurations, **Then**, each operator is notified and provided with a means to specify a maintenance shutdown period during which their configuration will be automatically re-deployed. ## notes breaking changes to operator-facing configuration may be handled by any of: - migrating state / mappings (#629) - user action (aided by #214) ### implementation notes - handle application version updates in [service scripts](https://github.com/Fresheyeball/rfcs/blob/master/rfcs/0155-nixos-migrations.md#up-script) - by application (also see our [apps sheet](https://git.fediversity.eu/Fediversity/apps-sheet/media/branch/main/apps.ods)'s `upgrade` column) - [mastodon](https://docs.joinmastodon.org/admin/upgrading/) - [pixelfed](https://docs.pixelfed.org/running-pixelfed/administration.html#updating-pixelfed) - [peertube](https://docs.joinpeertube.org/install/any-os#upgrade)

Niols added this to the Fediversity project

2025-02-19 17:10:17 +01:00

fricklerhandwerk changed title from ~~Support hosting providers updating their operators' deployments~~ to Hosting providers can update their operators' deployments

2025-02-19 18:29:41 +01:00

~~kiara referenced this issue 2025-02-25 12:12:17 +01:00~~

View difference between configured and deployed state #143

fricklerhandwerk commented

2025-02-25 13:00:28 +01:00

Owner

on versioning

Here's a sketch from the discussion @kiara and I had today about that issue. My way of phrasing this (to hopefully make the scribble easier to read): While NixOps4 allows managing configuration state in the time domain, version changes are another dimension we have to take care of. This complicates things quite a bit, but it's crucial to handle this in a principled manner, otherwise we'll run into trouble very soon and hosting providers will have to continuously, manually fight lots of code falling apart.

Likely the mappings between versions have to happen in resource providers, but we still need to figure out how to think about the various interactions that can happen, starting with how to display differences (#143) between "schemas" (e.g. of a service configuration) for each version, which may be different for "available", "configured", and "deployed" state.

There's probably some elegant mathematical approach to this that would allow us to write very little (very abstract) code, and we'd be good. Somethingsomething lattices...

edit: filed as #634

<details> <summary> on versioning </summary> Here's a sketch from the discussion @kiara and I had today about that issue. My way of phrasing this (to hopefully make the scribble easier to read): While NixOps4 allows managing configuration state in the time domain, version changes are another dimension we have to take care of. This complicates things quite a bit, but it's crucial to handle this in a principled manner, otherwise we'll run into trouble very soon and hosting providers will have to continuously, manually fight lots of code falling apart. Likely the mappings between versions have to happen in resource providers, but we still need to figure out how to think about the various interactions that can happen, starting with how to display differences (#143) between "schemas" (e.g. of a service configuration) for each version, which may be different for "available", "configured", and "deployed" state. There's probably some elegant mathematical approach to this that would allow us to write very little (very abstract) code, and we'd be good. Somethingsomething lattices... </details> edit: filed as #634

version-drift.png

183 KiB