projectsveltos/classifier

Sveltos Classifier dynamically classify a cluster based on run time information (Kubernetes version, deployed resources and more)

classifier's Issues

BUG:Create management cluster without clusterAPI. No classifier is deployed

Problem Description

Create a management cluster without ClusterAPI, just Sveltos clusters.

Classifiers fails with

"E0804 12:19:37.669821 1 cluster_utils.go:247] "failed to list all Cluster" err="failed to get API group resources: unable to retrieve the complete list of server APIs: cluster.x-k8s.io/v1beta1: the server could not find the requested resource" controller="classifier" controllerGroup="lib.projectsveltos.io" controllerKind="Classifier" Classifier="default-classifier" namespace="" name="default-classifier" reconcileID=708c13de-49fa-4986-a448-46fee4c13126 classifier="default-classifier"
"

cluster classification diagrams

User Story

As a developer I would like comprehensive documentation of the cluster classification flow.
For instance, when Classifier instance is created, it gets deployed in the managed clusters. And if classifier-agent is not already present, agent gets also deployed.
How the agent reacts to events (cluster upgrades, resources created/deleted) and how clusters match are reported back to management cluster and processed there.

Detailed Description

In order to make it easier for devs to quickly understand sveltos internals, in the documentation (https://projectsveltos.github.io/sveltos/) create a developer section with diagrams of above flow.

/kind documentation
/help
/good-first-issue

Deploy sveltos-agent separately from classifier instances

Currently, sveltos-agent (deployments + CRDs) are deployed in each managed cluster as part of deploying classifier instance.

This process should be independent. Those should be two separate workflows.

Add knob to instruct classifier where sveltos-agent needs to be deployed

Sveltos-agent must support being deployed in the managed cluster (current and default option) or the management cluster. Please refer to this for more info.

Classifier then needs a knob to be instructed where to start sveltos-agent.

When sveltos-agent needs to be deployed in the management cluster deploySveltosAgent needs to change. Better to have a separate function as:

1. sveltos-agent Deployment namespace needs to be same as cluster namespace
2. sveltos-agent Deployment name needs to contain cluster name and cluster-type in order to avoid collision
3. sveltos-agent Deployment selector needs to contain cluster name and cluster-type
4. sveltos-agent Deployment will only need Secret list/get permissions in the management cluster (in order to access the Secret containing the Kubeconfig to access cluster).

Another option would be to give sveltos-agent no permission in the management cluster and then directly get and pass the Kubeconfig when starting sveltos-agent.

I believe Deployment and (Cluster)Role for proxy-role are needed, though potentially all could be installed if namespaces/names are cluster aware.

classifier ClusterReconciler and SveltosClusterReconciler needs to delete all that was installed in the management cluster for a given cluster when cluster is deleted.

docker image

Currently for classifier (and all other sveltos microservices) all docker images are stored in docker-hub under namespace gianlucam76. Replace this to use namespace projectsveltos.

After changing it:

• make generate
• make manifests
• make classifier-agent

will take care of updating autogenerated yamls.