Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The labelSelector option for HelmRepositories and HelmReleases resources #7380

Open
kvaps opened this issue Jan 26, 2024 · 5 comments
Open
Labels
component/apis-server Issue related to kubeapps api-server kind/proposal An issue that reports a new feature proposal to be discussed

Comments

@kvaps
Copy link
Contributor

kvaps commented Jan 26, 2024

Summary

The labelSelector option that makes kubeapps work HelmRepositories and HelmReleases with specific label only.

Background and rationale

Hi we use FluxCD for various scenarios:

  • case 1. To configure main cluster (system Helm-charts)
  • case 2. To setup user applications with kubeapps
  • case 3. Some of user applications may consist of various sub-charts installed the same way with FluxCD
  • case 4. User can install Kubernetes cluster as the application, this cluster is provisioned using cluster-api and we also use FluxCD to configure these clusters.

The case 1 can be simple solved by limiting user permissions for system apps, while the case 3 and case 4 are not.
Users must have a specific permissions to access HelmRepositories and install HelmReleases used for case 3 and case 4

For that reason I want to make kubeapps ingnore specific HelmRepositories and HelmReleases with specific label.
Or it's better to make it ignore all possible resources if they have no specifc label only.

Description

Introduce additional option to limit specific resources set. This also might be useful to installing two independent kubeapss in a single cluster

Acceptance criteria
A formalized list of conditions that ensure that the feature can be considered as finished.

Additional context
Add any other context or screenshots about the feature request here.

@kvaps kvaps added the kind/proposal An issue that reports a new feature proposal to be discussed label Jan 26, 2024
@antgamdia
Copy link
Contributor

Thanks for sharing the use cases, it's always great to see how Kubeapps could potentially fit in a wide range of scenarios.

(...) make kubeapps ignore specific HelmRepositories and HelmReleases with specific label.
Or it's better to make it ignore all possible resources if they have no specific label only.

Sounds like something doable, yep. With a certain flag to include/exclude based on a set of labels we could control if the CR (AppRepository -helm direct-, HelmRepository et al - helm via flux- or PackageRepository et al - carvel pkgs-) is processed by Kubeapps or not.
However, unless we also propagate these labels to the resources created by Flux and KappController, Kubeapps will display them. I mean, if a HelmRepositories does include the foo label, but the HelmRelease does not, Kubeapps will still display it.
Nonetheless, I assume it is something we could set in the package manager.

With regards to the implementation itself, I assume you only want to "hide" these resources in Kubeapps, not in the entire cluster. If it were the case, an AdmissionController could be used instead.
I assume we could set an option in the kubeapps-apis level, then passed back to the plugins and implemented in each of them.
Not difficult, but a bit tedious to implement perhaps. Right now, we have a very limited bandwidth, but we are more than happy to accept contributions.

Again, thanks for the proposal and sharing your use cases!

@antgamdia antgamdia added the component/apis-server Issue related to kubeapps api-server label Jan 26, 2024
@antgamdia antgamdia added this to the Community requests milestone Jan 26, 2024
@kvaps
Copy link
Contributor Author

kvaps commented Jan 27, 2024

@antgamdia thank you for your response.

Currently I'm going to add dirty hack to filter out the helm repos and helm releases with specific label

It seems the right place for that:

listOptions := ctrlclient.ListOptions{
Namespace: ns,
}
if err := client.List(backgroundCtx, &repoList, &listOptions); err != nil {

if err = client.List(ctx, &relList); err != nil {

And later if we'd like to specify a label for a newly created releases, it can be done here:

ObjectMeta: metav1.ObjectMeta{
Name: targetName.Name,
Namespace: targetName.Namespace,
},

Please correct me if I'm wrong

@kvaps
Copy link
Contributor Author

kvaps commented Jan 27, 2024

Yeah, I can confirm that this patch works fine:

diff --git a/cmd/kubeapps-apis/plugins/fluxv2/packages/v1alpha1/release.go b/cmd/kubeapps-apis/plugins/fluxv2/packages/v1alpha1/release.go
index fe7ca772d..3b46afbd1 100644
--- a/cmd/kubeapps-apis/plugins/fluxv2/packages/v1alpha1/release.go
+++ b/cmd/kubeapps-apis/plugins/fluxv2/packages/v1alpha1/release.go
@@ -29,8 +29,10 @@ import (
 	"k8s.io/apimachinery/pkg/api/errors"
 	"k8s.io/apimachinery/pkg/api/meta"
 	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
+	"k8s.io/apimachinery/pkg/labels"
 	"k8s.io/apimachinery/pkg/types"
 	log "k8s.io/klog/v2"
+	ctrlclient "sigs.k8s.io/controller-runtime/pkg/client"
 	"sigs.k8s.io/yaml"
 )
 
@@ -54,7 +56,10 @@ func (s *Server) listReleasesInCluster(ctx context.Context, headers http.Header,
 	// see any results created/updated/deleted after the first request is issued
 	// To fix this, we must make use of resourceVersion := relList.GetResourceVersion()
 	var relList helmv2.HelmReleaseList
-	if err = client.List(ctx, &relList); err != nil {
+	listOptions := ctrlclient.ListOptions{
+		LabelSelector: labels.SelectorFromSet(labels.Set{"cozystack.io/ui": "true"}),
+	}
+	if err = client.List(ctx, &relList, &listOptions); err != nil {
 		return nil, connecterror.FromK8sError("list", "HelmRelease", namespace+"/*", err)
 	} else {
 		return relList.Items, nil
@@ -511,6 +516,9 @@ func (s *Server) newFluxHelmRelease(chart *models.Chart, targetName types.Namesp
 		ObjectMeta: metav1.ObjectMeta{
 			Name:      targetName.Name,
 			Namespace: targetName.Namespace,
+			Labels: map[string]string{
+				"cozystack.io/ui": "true",
+			},
 		},
 		Spec: helmv2.HelmReleaseSpec{
 			Chart: helmv2.HelmChartTemplate{
diff --git a/cmd/kubeapps-apis/plugins/fluxv2/packages/v1alpha1/repo.go b/cmd/kubeapps-apis/plugins/fluxv2/packages/v1alpha1/repo.go
index 1ab08c074..cd7b3b9aa 100644
--- a/cmd/kubeapps-apis/plugins/fluxv2/packages/v1alpha1/repo.go
+++ b/cmd/kubeapps-apis/plugins/fluxv2/packages/v1alpha1/repo.go
@@ -32,6 +32,7 @@ import (
 	apiv1 "k8s.io/api/core/v1"
 	"k8s.io/apimachinery/pkg/api/meta"
 	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
+	"k8s.io/apimachinery/pkg/labels"
 	"k8s.io/apimachinery/pkg/types"
 	"k8s.io/apimachinery/pkg/util/sets"
 	log "k8s.io/klog/v2"
@@ -64,7 +65,8 @@ func (s *Server) listReposInNamespace(ctx context.Context, headers http.Header,
 
 	var repoList sourcev1.HelmRepositoryList
 	listOptions := ctrlclient.ListOptions{
-		Namespace: ns,
+		Namespace:     ns,
+		LabelSelector: labels.SelectorFromSet(labels.Set{"cozystack.io/ui": "true"}),
 	}
 	if err := client.List(backgroundCtx, &repoList, &listOptions); err != nil {
 		return nil, connecterror.FromK8sError("list", "HelmRepository", "", err)

Copy link

stale bot commented Mar 17, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale Automatic label to stale issues due inactivity to be closed if no further action label Mar 17, 2024
@kvaps
Copy link
Contributor Author

kvaps commented Mar 17, 2024

This is still in a row

@antgamdia antgamdia removed the stale Automatic label to stale issues due inactivity to be closed if no further action label Mar 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/apis-server Issue related to kubeapps api-server kind/proposal An issue that reports a new feature proposal to be discussed
Projects
Status: 🗂 Backlog
Development

No branches or pull requests

2 participants