Problem Statement
Today, the control plane assumes that a service's public URL is always derived from its release name.
This assumption works for most services, but it doesn't fit services whose endpoint is defined by their role instead.
A good example is the project's default object storage. Regardless of whether it is backed by RustFS, SeaweedFS, or another implementation, users expect a single, stable endpoint for storage within the project. That endpoint should not depend on the name given to the service instance.
Today, the control plane only looks for an Ingress matching <release-name>.<suffix>. If the service follows a different hostname convention (for example storage-<namespace>.<suffix>), the public URL cannot be resolved.
As a result:
- the service is healthy and reachable;
- the control plane cannot determine its public URL;
- the console does not display the Open button.
This limitation is not specific to storage. Any service whose public endpoint follows a role-based convention rather than a release-name convention would face the same issue. For example a project-wide database, an identity provider (IdP), or other shared platform services.
Proposed Solution
Extend service URL resolution to support role-based hostname conventions in addition to the existing release-name lookup.
The current behavior should remain unchanged for existing services. If no URL can be resolved from the release name, the control plane can fall back to role-specific conventions when appropriate.
This keeps backward compatibility while allowing platform-wide services, such as storage, to expose stable URLs independent of the instance name.
Benefits
-
Supports project-wide services with stable URLs.
For example, a project's default storage can always be reached at storage-<namespace>.<suffix>, regardless of whether it is backed by RustFS, SeaweedFS, or another implementation.
-
Decouples service discovery from instance names.
For example, renaming a storage instance from storage to my-storage, or switching from SeaweedFS to RustFS, does not affect the URL exposed by the control plane or the console's Open button.
-
Preserves existing behavior for current services.
For example, services such as JupyterHub, Superset, and Polaris continue to resolve their URLs using the existing
<release-name>.<suffix> convention. Role-based resolution is only used when the standard lookup does not apply.
-
Makes new service roles easy to support.
For example, if a future identity or catalog service needs a stable hostname convention, it can be added without changing the URL resolution
algorithm itself.
Alternatives Considered
No response
Additional Context
This is a follow-up to okdp-sandbox#67, which fixed the sandbox provider configuration.
That issue ensured the correct URLs are exposed by the provider context. This feature enables the control plane to resolve those URLs when they follow role-based conventions instead of release-name conventions.
Problem Statement
Today, the control plane assumes that a service's public URL is always derived from its release name.
This assumption works for most services, but it doesn't fit services whose endpoint is defined by their role instead.
A good example is the project's default object storage. Regardless of whether it is backed by RustFS, SeaweedFS, or another implementation, users expect a single, stable endpoint for storage within the project. That endpoint should not depend on the name given to the service instance.
Today, the control plane only looks for an Ingress matching
<release-name>.<suffix>. If the service follows a different hostname convention (for examplestorage-<namespace>.<suffix>), the public URL cannot be resolved.As a result:
This limitation is not specific to storage. Any service whose public endpoint follows a role-based convention rather than a release-name convention would face the same issue. For example a project-wide database, an identity provider (IdP), or other shared platform services.
Proposed Solution
Extend service URL resolution to support role-based hostname conventions in addition to the existing release-name lookup.
The current behavior should remain unchanged for existing services. If no URL can be resolved from the release name, the control plane can fall back to role-specific conventions when appropriate.
This keeps backward compatibility while allowing platform-wide services, such as storage, to expose stable URLs independent of the instance name.
Benefits
Supports project-wide services with stable URLs.
For example, a project's default storage can always be reached at
storage-<namespace>.<suffix>, regardless of whether it is backed by RustFS, SeaweedFS, or another implementation.Decouples service discovery from instance names.
For example, renaming a storage instance from
storagetomy-storage, or switching from SeaweedFS to RustFS, does not affect the URL exposed by the control plane or the console's Open button.Preserves existing behavior for current services.
For example, services such as JupyterHub, Superset, and Polaris continue to resolve their URLs using the existing
<release-name>.<suffix>convention. Role-based resolution is only used when the standard lookup does not apply.Makes new service roles easy to support.
For example, if a future
identityorcatalogservice needs a stable hostname convention, it can be added without changing the URL resolutionalgorithm itself.
Alternatives Considered
No response
Additional Context
This is a follow-up to okdp-sandbox#67, which fixed the sandbox provider configuration.
That issue ensured the correct URLs are exposed by the provider context. This feature enables the control plane to resolve those URLs when they follow role-based conventions instead of release-name conventions.