servala/servala-portal

Fork 0

Hardcoded parameter values per Service Offering #294

New issue

Closed

opened 2025-11-14 10:02:29 +00:00 by tobru · 3 comments

tobru commented

2025-11-14 10:02:29 +00:00

Owner

Stories

As a platform operator, I want to hardcode some values per service offering

Implementation Notes

This is intended for the Codey use case, where we currently hardcode some values in the Codey XRD on the control plane.

For specific SaaS service offerings, we need to hardcode some parameters, which cannot be changed by the user. Make it possible to configure hardcoded values per service offering, which are then passed to the control plane on service creation and editing.

We may want to have hardcoded parameters depending on the chosen plan, because some settings could be dependent on this. It's not clear if we should already do this in this issue or if we should do that in a separate iteration later.

Links

## Stories _As a platform operator, I want to hardcode some values per service offering_ ## Implementation Notes This is intended for the Codey use case, where we currently hardcode some values in the Codey XRD on the control plane. For specific SaaS service offerings, we need to hardcode some parameters, which cannot be changed by the user. Make it possible to configure hardcoded values per service offering, which are then passed to the control plane on service creation and editing. We may want to have hardcoded parameters depending on the chosen plan, because some settings could be dependent on this. It's not clear if we should already do this in this issue or if we should do that in a separate iteration later. ### Links - https://kb.vshn.ch/app-catalog/service/forgejo-codey/architecture.html - https://github.com/vshn/component-appcat/blob/develop/tests/golden/dev/appcat/appcat/21_composition_vshn_codey.yaml#L68 - https://vshnticket.atlassian.net/browse/APPCAT-1187

tobru added this to the SaaS Applications milestone

2025-11-14 10:02:29 +00:00

tobru added the

enhancement

label

2025-11-14 10:02:29 +00:00

tobru added this to the Development Planning project

2025-11-14 10:02:29 +00:00

rixx commented

2026-01-19 16:04:45 +00:00

Member

@tobru Should the hardcoded fields be just hidden in the form UI? I built it like that for now, but we can also show them as read-only fields if you prefer.

rixx commented

2026-01-19 16:49:21 +00:00

Member

@tobru Second question: In which order are we applying hard-coded fields and compute plan fields? I assume these should typically not interact (ie some values are set via compute plan, completely different values are set via CRD-level hard-coded fields). But if they were to be in conflict, which ones should win out?

@tobru Second question: In which order are we applying hard-coded fields and compute plan fields? I assume these should typically not interact (ie some values are set via compute plan, completely different values are set via CRD-level hard-coded fields). But *if* they were to be in conflict, which ones should win out?

rixx referenced this issue from a commit

2026-01-19 17:06:42 +00:00

Implement hardcoded params at CRD level

rixx referenced this issue

2026-01-19 17:06:49 +00:00

Implement hardcoded params at CRD level #354

tobru commented

2026-01-20 07:05:04 +00:00

Author

Owner

Should the hardcoded fields be just hidden in the form UI? I built it like that for now, but we can also show them as read-only fields if you prefer.

Yes, let's keep them hidden in the UI for now.

Second question: In which order are we applying hard-coded fields and compute plan fields? I assume these should typically not interact (ie some values are set via compute plan, completely different values are set via CRD-level hard-coded fields). But if they were to be in conflict, which ones should win out?

Compute plans would have precedence.

> Should the hardcoded fields be just hidden in the form UI? I built it like that for now, but we can also show them as read-only fields if you prefer. Yes, let's keep them hidden in the UI for now. > Second question: In which order are we applying hard-coded fields and compute plan fields? I assume these should typically not interact (ie some values are set via compute plan, completely different values are set via CRD-level hard-coded fields). But if they were to be in conflict, which ones should win out? Compute plans would have precedence.

rixx referenced this issue from a commit

2026-01-22 13:06:27 +00:00

Implement hardcoded params at CRD level

tobru closed this issue

2026-01-22 14:23:21 +00:00

tobru referenced this issue

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

Update service when hardcoded parameters change #373