fediversity/fediversity

Watch

Fork 10

panel: Application Instances list for Operator #1256

New issue

Closed

opened 2026-07-31 20:39:59 +02:00 by kerstin · 8 comments

kerstin commented

2026-07-31 20:39:59 +02:00

Member

As an operator using the panel
I want to view all the fediversity application instances that I operate
so that I can

understand what instances I run
add more instances
navigate to the individual instances to further manipulate them

I do not want to

see hosting-provider facing configuration
understand what a deployment group or ancillary nodes are
see what kind of virtualisation technology is used for the instance and how many nodes it consists of

This is related to

operator has front-end #673
update or remove instances #180
update instances #158

**As** an operator using the panel **I want** to view all the fediversity application instances that I operate **so that** I can - understand what instances I run - add more instances - navigate to the individual instances to further manipulate them I do **not** want to - see hosting-provider facing configuration - understand what a deployment group or ancillary nodes are - see what kind of virtualisation technology is used for the instance and how many nodes it consists of This is related to - operator has front-end https://git.fediversity.eu/fediversity/fediversity/issues/673 - update or remove instances https://git.fediversity.eu/fediversity/fediversity/issues/180 - update instances https://git.fediversity.eu/fediversity/fediversity/issues/158

kerstin added this to the Fediversity project

2026-07-31 20:40:05 +02:00

kerstin self-assigned this

2026-07-31 20:40:07 +02:00

kiara commented

2026-07-31 21:27:34 +02:00

Owner

and pay for

note that, so far, instances have not been a billing unit: as open-source software fediversity itself technically has no notion of billing, and procolix's productization effort similarly intends to have things as a package deal spanning a single set of application instances (i.e. one instance per application, without even necessarily an option to opt out of individual applications).

add more instances

this would imply to me applications have no dependencies (ancilliary nodes), or alternatively, that one would be free to reconfigure instances into deployment groups on the same set of ancilliary nodes.
that maybe raises the question: in what ways does the current model not suffice? i'm not so much claiming that it would, but if we could understand the operator needs not sufficiently serviced by this model better, then that could perhaps help better inform how to approach things here.

> and pay for note that, so far, instances have not been a billing unit: as open-source software fediversity itself technically has no notion of billing, and procolix's productization effort similarly intends to have things as a package deal spanning a single set of application instances (i.e. one instance per application, without even necessarily an option to opt out of individual applications). > add more instances this would imply to me applications have no dependencies (ancilliary nodes), or alternatively, that one would be free to reconfigure instances into deployment groups on the same set of ancilliary nodes. that maybe raises the question: in what ways does the current model not suffice? i'm not so much claiming that it _would_, but if we could understand the operator needs not sufficiently serviced by this model better, then that could perhaps help better inform how to approach things here.

kerstin commented

2026-08-04 12:38:51 +02:00

Author

Member

instances have not been a billing unit

Good to know.

that maybe raises the question: in what ways does the current model not suffice?

I don't understand this. I'm not trying to change the model here, I'm trying to build an interface for the current model.

> instances have not been a billing unit Good to know. > that maybe raises the question: in what ways does the current model not suffice? I don't understand this. I'm not trying to change the model here, I'm trying to build an interface for the current model.

kiara commented

2026-08-04 13:20:10 +02:00

Owner

I'm not trying to change the model here, I'm trying to build an interface for the current model.

nodes in an (abstract) group are currently tracked mostly in core/setups/groups/<group>.nix, which should be exposed thru core#lib.baseGroups. core/setups/hosts-common.nix then uses this to deploy these.

such deployed machines may be tracked mostly in terraform state, tho telemetry may also give a sense of the nodes in a set.
that TF state may be queried using some of the TF verbs exposed by core/.

to set expectations, there is no such notion of instances at:

panel's data model
core/lib/data-model.nix
the param sets of deployment methods exposed thru core/setups/hosts-common.nix

> I'm not trying to change the model here, I'm trying to build an interface for the current model. nodes in an (abstract) group are currently tracked mostly in `core/setups/groups/<group>.nix`, which should be exposed thru `core#lib.baseGroups`. `core/setups/hosts-common.nix` then uses this to deploy these. such _deployed_ machines may be tracked mostly in terraform state, tho telemetry may also give a sense of the nodes in a set. that TF state may be queried using some of the [TF verbs](https://core.pages.git.fediversity.eu/flake-attributes.html#verbs) exposed by `core/`. to set expectations, there is no such notion of instances at: - panel's data model - `core/lib/data-model.nix` - the param sets of deployment methods exposed thru `core/setups/hosts-common.nix`

kerstin commented

2026-08-04 13:20:58 +02:00

Author

Member

this would imply to me applications have no dependencies

Imo applications do not have other applications as dependencies. I just see no example of where they would. Please provide an example. SSO is not an example of inter-applications dependency, as SSO relations aren't configured through nix, at least I haven't seen a case yet where Nix Code provisions e.g. an OIDC client.

> this would imply to me applications have no dependencies Imo applications _do not_ have other applications as dependencies. I just see no example of where they would. Please provide an example. SSO is not an example of inter-applications dependency, as SSO relations aren't configured through nix, at least I haven't seen a case yet where Nix Code provisions e.g. an OIDC client.

kerstin commented

2026-08-04 13:24:00 +02:00

Author

Member

nodes in an (abstract) group

deployed machines

terraform state

nodes in a set

These are all concepts we wanna completely hide from the operator, right?

> nodes in an (abstract) group > deployed machines > terraform state > nodes in a set These are all concepts we wanna completely hide from the operator, right?

kerstin changed title from ~~panel: application instances list for operator~~ to panel: Application Instances list for Operator

2026-08-04 13:52:52 +02:00

kiara referenced this issue

2026-08-04 13:57:35 +02:00

distinguish use of term 'application' #1280

kiara commented

2026-08-04 14:18:38 +02:00

Owner

applications do not have other applications as dependencies

this sounds like a matter of semantics to me, so i've filed #1280 to try and address that - because presumably we agree that applications may depend on services like databases, and in our data model those currently have ended up utilizing our application data model entity as well.

SSO relations aren't configured through nix, at least I haven't seen a case yet where Nix Code provisions e.g. an OIDC client.

we currently handle all that thru nix, see core/resource/oidc/.

These are all concepts we wanna completely hide from the operator, right?

i think they would facilitate exposing the info you do want exposed to them - in that sense i'm not sure i'd see them as completely separate.

> applications _do not have_ other applications as dependencies this sounds like a matter of semantics to me, so i've filed #1280 to try and address that - because presumably we agree that applications may depend on services like databases, and in our data model those _currently_ have ended up utilizing our `application` _data model_ entity as well. > SSO relations aren't configured through nix, at least I haven't seen a case yet where Nix Code provisions e.g. an OIDC client. we currently handle all that thru nix, see `core/resource/oidc/`. > These are all concepts we wanna completely hide from the operator, right? i think they would facilitate exposing the info you _do_ want exposed to them - in that sense i'm not sure i'd see them as completely separate.

toonn modified the project from Fediversity to Dev

2026-08-04 14:56:30 +02:00

kiara referenced this issue from fediversity/meta

2026-08-04 16:30:57 +02:00

distinguish use of term 'application' #39

kerstin commented

2026-08-04 18:10:13 +02:00

Author

Member

this sounds like a matter of semantics to me

From the glossary:

Application

User-facing software run fully automated by the hosting provider for an operator.

Then the data model needs to be adapted to the glossary. A database is not user-facing…

we currently handle all that thru nix, see core/resource/oidc/.

Good to know, I'll look at that.

> this sounds like a matter of semantics to me From the glossary: > - Application > > User-facing software run fully automated by the hosting provider for an operator. Then the data model needs to be adapted to the glossary. A database is not user-facing… > we currently handle all that thru nix, see core/resource/oidc/. Good to know, I'll look at that.

kiara referenced this issue

2026-08-20 17:36:16 +02:00

core/components: expose the upstream NixOS service options #1384

kiara added the

ambition

front-end

label

2026-08-24 23:18:42 +02:00

kiara commented

2026-09-21 15:49:14 +02:00

Owner

i think this is implemented now ✌️