Repository navigation
Extract SveltosCluster expired token controller #1985
Description
Activity
- added a parent issue
on Sep 12, 2025 So, I'm going to move following controllers:
kcm/internal/controller/adapters/sveltos/cluster_controllerkcm/internal/controller/adapters/sveltos/serviceset_controller
to separate repository, say
ksm-projectsveltos-provider, since both of listed controllers required in only single case when k0rdent uses the ProjectSveltos as an underlying CD provider.We'll then include
ksm-projectsveltos-providerchart as a dependency for projectsveltos.
Both controllers - cluster_* and serviceset_* - will be configurable via helm values.I wonder how scripting part of credentials be handled in case of Sveltos being optional, k0rdent is going to ship multiple versions of provider templates for each CD implementation?
I wonder how scripting part of credentials be handled in case of Sveltos being optional, k0rdent is going to ship multiple versions of provider templates for each CD implementation?
Could you elaborate what do you mean? How does credentials depends directly on Sveltos? Regarding provider templates - user can create anf use custom provider templates or I miss something?
4 remaining items
From UX side, credential propagation is already not stable, since the projectsveltos provider could be disabled:
- Option 1 - we do not extract controllers and leave things as is. User disables projectsveltos provider -> credential propagation doesn't work.
- Option 2 - we extract controllers and make them part of projectsveltos provider. User disables projectsveltos provider -> credential propagation doesn't work.
- Option 3 - user doesn't disable projectsveltos provider -> in either case all required controllers are shipped -> credential propagation works.
I do not argue about necessity of revisiting the credential propagation approach. I just want to highlight that this feature won't work if the projectsveltos provider will be disabled disregard of how related controllers will be shipped to the platform.
since the projectsveltos provider could be disabled
A simple webhook change can fix that
Doesn't look reasonable: we put sveltos as a provider to release spec, so user would expect it could disabled.
On the other hand pinning such a dependency could potentially cut off a bunch of customers in case sveltos doesn't meet their compliance.Doesn't look reasonable: we put sveltos as a provider to release spec, so user would expect it could disabled. On the other hand pinning such a dependency could potentially cut off a bunch of customers in case sveltos doesn't meet their compliance.
In that case above arguments in #1985 (comment) do not make sense.
If consumer disables Sveltos, he breaks functionality of some (all?) providers and k0rdent is ok with that.
In that case above arguments in #1985 (comment) do not make sense.
If consumer disables Sveltos, he breaks functionality of some (all?) providers and k0rdent is ok with that.
why? we do not rely on sveltos to deploy clusters. Sveltos is only used to deliver workloads/resources to child clusters.
kcm will work perfectly fine without sveltos, except cred propagation part, of course.Sveltos is only used for adopted cluster template.
So I really can't get your concerns, since such extraction won't change things in general. Fix me if I'm wrong.
I'd say that we'd make some effort to get rid of the remaining dependencies rather than nailing kcm tightly to sveltos.
kcm will work perfectly fine without Sveltos
so you are saying k0rdent is already migrated off Sveltos Cluster object and it is not the underlying foundation of CLD object?
kcm will work perfectly fine without sveltos, except cred propagation part, of course.
there is a reason why some providers needs credentials and you can't say that your newly created child cluster is in perfect working order when that child cluster has broken CCM setup
So, no KCM right now can't work without Sveltos
so you are saying k0rdent is already migrated off Sveltos Cluster object and it is not the underlying foundation of CLD object?
grep -A 1 -R --include="*.yaml" -E "apiVersion: .*projectsveltos.io/v1beta1" templates/ templates/cluster/adopted-cluster/templates/sveltoscluster.yaml:apiVersion: lib.projectsveltos.io/v1beta1 templates/cluster/adopted-cluster/templates/sveltoscluster.yaml-kind: SveltosClustergrep -R --exclude-dir={test,adapters,v1alpha1} --include="*.go" --exclude="*_test.go" -E "SveltosCluster" ./ ./cmd/main.go: flag.BoolVar(&enableSveltosExpireCtrl, "enable-sveltos-expire-ctrl", false, "Enable SveltosCluster stuck (expired) tokens controller") ./cmd/main.go: setupLog.Error(err, "unable to create controller", "controller", "SveltosCluster") ./internal/telemetry/collector/common.go:// to match [github.com/projectsveltos/libsveltos/api/v1beta1.SveltosCluster] labels instead of ./api/v1beta1/multiclusterservice_types.go: // SveltosClusterProfileReadyCondition indicates if the Sveltos ClusterProfile is ready. ./api/v1beta1/multiclusterservice_types.go: SveltosClusterProfileReadyCondition = "SveltosClusterProfileReady" ./api/v1beta1/multiclusterservice_types.go: // SveltosClusterProfileNotReadyReason signals that the Sveltos ClusterProfile object is not yet ready. ./api/v1beta1/multiclusterservice_types.go: SveltosClusterProfileNotReadyReason = "SveltosClusterProfileNotReady" ./api/v1beta1/clusterdeployment_types.go: // SveltosClusterReadyCondition indicates the sveltos cluster is valid and ready. ./api/v1beta1/clusterdeployment_types.go: SveltosClusterReadyCondition = "SveltosClusterReady"Yes, SveltosCluster is only used for adopted cluster.
there is a reason why some providers needs credentials and you can't say that your newly created child cluster is in perfect working order when that child cluster has broken CCM setup
So, no KCM right now can't work without Sveltos
I understand this. And I do not talk about complete sveltos removal. I only say that sveltos is already could be disabled. This is a fact. And moving controllers from one repo to another, taking into account that extracted controllers will be shipped with sveltos, makes absolutely no difference with the current state.
So we are back to this question #1985 (comment)
As a consumer I want to understand all of this moving around before it happens.
on pause until decision made
Design doc for resources propagation without using sveltos: https://docs.google.com/document/d/1JDAVnJLr0_GkC3Jxwxr7MwmbNnbC5v90BKPSvgF_BXY/edit?usp=sharing
Metadata
Metadata
Assignees
Type
Projects
- Status
Currently, the KCM controller includes the SveltosCluster token expiration controller. Since SveltosCluster is part of a regional API, the KCM controller cannot reconcile SveltosClusters on regional clusters.
To address this, the controller should be extracted from KCM and deployed on regional clusters as part of the
projectsveltosHelm chart.It must also: