Update instances on control planes when configuration changes #373

New issue

Open

opened 2026-01-26 13:58:20 +00:00 by tobru · 0 comments

tobru commented

2026-01-26 13:58:20 +00:00

Owner

Stories

As a service operator, I want to make sure service instances adhere to hardcoded parameters when they change

Implementation Notes

One example use case: For Codey we hardcode spec.parameters.service.majorVersion. Once a new Forgejo major version is out, we want to change the version number and make sure all Codey instances are upgraded accordingly.

As a follow-up to #294: when certain parameters are changed in the Portal database, update all service instances on the control-planes to make sure the new parameters are adapted accordingly.

Hardcoded parameters in controlplanecrd
Plan parameters (limits, requests)
Annotations

Implement this as an admin command that first compares the current instance configuration on the control-plane with the intended configuration from the portal, then shows a diff and asks for confirmation.

Basically, we need a reconciliation that makes sure that instances on the control plane reflect the configuration the portal assumes to be there. The portal is the source of truth for the mentioned hardcoded parameters; it's not intended that service configuration get changed on the control plane outside the portal.

## Stories _As a service operator, I want to make sure service instances adhere to hardcoded parameters when they change_ ## Implementation Notes One example use case: For Codey we hardcode `spec.parameters.service.majorVersion`. Once a new Forgejo major version is out, we want to change the version number and make sure all Codey instances are upgraded accordingly. As a follow-up to #294: when certain parameters are changed in the Portal database, update all service instances on the control-planes to make sure the new parameters are adapted accordingly. - Hardcoded parameters in controlplanecrd - Plan parameters (limits, requests) - Annotations Implement this as an admin command that first compares the current instance configuration on the control-plane with the intended configuration from the portal, then shows a diff and asks for confirmation. Basically, we need a reconciliation that makes sure that instances on the control plane reflect the configuration the portal assumes to be there. The portal is the source of truth for the mentioned hardcoded parameters; it's not intended that service configuration get changed on the control plane outside the portal.