update or remove deployments

kiara commented

2025-02-24 09:28:08 +01:00

Owner

As a Fediversity user,
I want my configuration changes to automatically remove existing VMs or provision new VMs.

Test:

Given I have an existing deployment,
When I change my configuration and run deployment,
Then, the state of the virtualisation component is updated according (e.g. removing VMs, provisioning VMs, changing VM parameters).

**As** a Fediversity user, **I want** my configuration changes to automatically remove existing VMs or provision new VMs. ### Test: **Given** I have an existing deployment, **When** I change my configuration and run deployment, **Then**, the state of the virtualisation component is updated according (e.g. removing VMs, provisioning VMs, changing VM parameters).

kiara added a new dependency

2025-02-24 09:29:05 +01:00

#158 users can update their deployment configurations

kiara added a new dependency

2025-02-24 11:16:15 +01:00

#186 allow disabling service while retaining data

kiara added the

type

user-story

label

2025-05-01 12:04:54 +02:00

kiara added the

points

5

label

2025-12-02 22:47:29 +01:00

kiara added a new dependency

2025-12-03 00:01:26 +01:00

#188 garbage collection of unallocated resources

kiara commented

2026-05-30 14:26:59 +02:00

Author

Owner

~~[ ] tweak node parameters~~
removal:
- #886
- #1036

edit: removal of the VM/container we can do, but not beyond yet, see below

- ~~[ ] tweak node parameters~~ - [x] removal: - #886 - #1036 edit: removal of the VM/container we can do, but not beyond yet, see below

kiara commented

2026-06-06 14:19:47 +02:00

Author

Owner

actually, who's to say we need operators to tweak such params, particularly now we went from VMs to containers (#914)

kiara closed this issue

2026-06-06 14:19:48 +02:00

toonn commented

2026-06-08 12:23:00 +02:00

Member

What parameters are you referring to? Regardless of whether an Application is run on a VM or a container, when deploying a new configuration, if the VM/container is no longer necessary it should be cleaned up.

(Usually the declarative approach is to always remove everything and do a fresh deployment but that does cause undesirable downtime.)

What parameters are you referring to? Regardless of whether an Application is run on a VM or a container, when deploying a new configuration, if the VM/container is no longer necessary it should be cleaned up. (Usually the declarative approach is to always remove everything and do a fresh deployment but that does cause undesirable downtime.)

kiara commented

2026-06-08 14:25:14 +02:00

Author

Owner

for VMs one would allocate like RAM/disk, tho i think the LXC containers have been sorta more fungible in that regard

toonn commented

2026-06-08 16:12:31 +02:00

Member

I agree that those shouldn't be exposed to Operators (maybe by proxy in the form of hardware tiers for your Applications, but out of scope for us IMO). I don't see this as a motivation to close the issue.

This issue is more about something like an Operator deciding to use a different Matrix server, switching from Synapse to Continuwuity for example. The Operator mostly only cares that the Continuwuity instance is deployed, but the Hosting Provider cares about removing the defunct Synapse VM/container to avoid wasting resources.

I agree that those shouldn't be exposed to Operators (maybe by proxy in the form of hardware tiers for your Applications, but out of scope for us IMO). I don't see this as a motivation to close the issue. This issue is more about something like an Operator deciding to use a different Matrix server, switching from Synapse to Continuwuity for example. The Operator mostly only cares that the Continuwuity instance is deployed, but the Hosting Provider cares about removing the defunct Synapse VM/container to avoid wasting resources.

kiara commented

2026-06-08 16:28:30 +02:00

Author

Owner

I agree that those shouldn't be exposed to Operators (maybe by proxy in the form of hardware tiers for your Applications, but out of scope for us IMO). I don't see this as a motivation to close the issue.

i agree on both counts. i expect for the productized front-end not to expose this, tho for the reference front-end, i do wanna think it makes sense to demonstrate what we can do. that effort i intend to now track in #723.

This issue is more about something like an Operator deciding to use a different Matrix server, switching from Synapse to Continuwuity for example. The Operator mostly only cares that the Continuwuity instance is deployed, but the Hosting Provider cares about removing the defunct Synapse VM/container to avoid wasting resources.

i'm not confident cross-application migrations are low-hanging fruit, but feel free to file a ticket better fleshing out this use-case if you feel more optimistic

> I agree that those shouldn't be exposed to Operators (maybe by proxy in the form of hardware tiers for your Applications, but out of scope for us IMO). I don't see this as a motivation to close the issue. i agree on both counts. i expect for the productized front-end not to expose this, tho for the reference front-end, i do wanna think it makes sense to demonstrate what we can do. that effort i intend to now track in #723. > This issue is more about something like an Operator deciding to use a different Matrix server, switching from Synapse to Continuwuity for example. The Operator mostly only cares that the Continuwuity instance is deployed, but the Hosting Provider cares about removing the defunct Synapse VM/container to avoid wasting resources. i'm not confident cross-application migrations are low-hanging fruit, but feel free to file a ticket better fleshing out this use-case if you feel more optimistic

toonn commented

2026-06-09 13:13:00 +02:00

Member

I'm not even talking about migration. Just that at some point some deployed service will no longer be in use and need to be cleaned up, you can do such cleanup when an Operator deploys a config with the service disabled but what if an Operator simply stops paying bills? You can't count on the cleanup being triggered only by an Operator action.

kiara commented

2026-06-09 14:34:53 +02:00

Author

Owner

what if an Operator simply stops paying bills? You can't count on the cleanup being triggered only by an Operator action.

right - maybe #1068 could cover that?

at some point some deployed service will no longer be in use and need to be cleaned up

you're right - so far tf-incus's delete just prunes the LXC container, but in practice applications touch state across various shared infrastructure as well (db, kv-store, s3, vault, TF back-end, ...). reopening. c.f. #186.

> what if an Operator simply stops paying bills? You can't count on the cleanup being triggered only by an Operator action. right - maybe #1068 could cover that? > at some point some deployed service will no longer be in use and need to be cleaned up you're right - so far `tf-incus`'s delete just prunes the LXC container, but in practice applications touch state across various shared infrastructure as well (db, kv-store, s3, vault, TF back-end, ...). reopening. c.f. #186.

👍 1

kiara reopened this issue

2026-06-09 14:34:56 +02:00

kiara changed title from ~~update or remove VMs~~ to update or remove deployments

2026-06-09 14:35:07 +02:00

kiara referenced this issue

2026-06-09 14:38:11 +02:00

allow disabling service while retaining data #186

kiara added a new dependency

2026-07-31 14:44:29 +02:00

#1224 Unable to delete a deployment in the panel