Is your feature request related to a problem? Please describe.

Currently, if there's an issue with a HelmChart or HelmRelease, a user will generally have to engage a Cluster Admin who has permissions to be able to ascertain what the issue with the underlying Helm release might be. However, it would be useful if the status of the Helm Release (including / specifically the Helm Job's logs, which would show what the error is) are accessible by a Project Owner or Project Member as well.

Describe the solution you'd like

Unclear; would love user feedback on this issue with examples of use cases and suggestions!

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

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

I installed Helm Project Operator with the provided Helm chart. With handle 20-30+ projects the Operator needs many recources, died with Oomkilled, and has not the right performance. The idea was to scale up the deployment, but the replicaset is hard coded to 1. This should be configurable, also to get more availability.

Note: cross-posted from https://github.com/aiyengar2/helm-project-operator/issues/2 on behalf of @ronhorton

this is in an rke2 ec2 downstream cluster

a. Click magnifying glass (search) in top menu

b. enter 'helm' in search field
c. select 'ProjectHemlCharts'
d. click Create from YAML
e. add name: demo
f. add namespace: cattle-project-p-ID from test-project namespace
g. add spec.helmapiversion: dummy.cattle.io/v1alpha1
h. click Create
i. Navigate to Workload > Jobs

expected: one job runs

actual result: job keeps getting created and added to the cattle-helm-namespace

Is your feature request related to a problem? Please describe.

Currently, every Helm Project Operator is forced to deploy both the controller that manages ProjectHelmCharts and the controller that manages hardening namespaces + creating project registration namespace all at once.

However, for users who want to configure multiple Helm Project Operators, they may want the definition of how Project Registration Namespaces are created and managed (i.e. hardenedNamespace.*, otherSystemProjectLabelValues, global.cattle.systemProjectId, global.cattle.projectLabel) to be managed independently of the configuration of the actual Helm Project Operator (e.g. valuesOverride, releaseRoleBindings.*, projectReleaseNamespaces.labelValues) to avoid multiple operators from trying to apply conflicting configurations.

Describe the solution you'd like

There should be a logical separation of controllers that are deployed such that they attempt to acquire locks independently and can be deployed standalone of each other.

Describe alternatives you've considered

Additional context

This would probably require a minor release since it's a major change in the way that the controllers are currently constructed that might require more rigorous QA and better understanding of how this would affect the user experience.

Currently, the k3s-io/helm-controller does not support auto-upgrading helm charts on seeing changes to the underlying cluster state that would result in a requirement to re-evaluate the Helm chart's contents.

This needs to be patched for k3s-io/helm-controller#141

Is your feature request related to a problem? Please describe.

Currently, Helm Project Operator assumes that it is deployed into a Rancher environment and assumes that the Project Release Namespaces are all in the System Project, which ensures that if Project Network Isolation is turned on (and Network Policies are used) that the Release Namespace is already configured to allow Pods to reach out into all namespaces (not just Project namespaces) since that's how all system project namespaces are configured.

However, in case a Rancher user would like to place the Project Release Namespaces outside the System project (e.g. to be able to set resource quotas across a dedicated release project) and is in this type of setup, since the Project Release namespaces are deployed with a default network policy allowing no ingress or egress, any action that requires reaching across to project namespaces (e.g. scraping custom metric workloads) will not be allowed.

Describe the solution you'd like

The Helm Chart should automatically create Network Policies allowing pods in the Project Release Namespace to reach out to all pods in any Project Namespace; these network policies should be configurable on a chart level.

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.

Currently, Helm Project Operator assumes that it is deployed into a Rancher environment and assumes that the Project Release Namespaces are all in the System Project, which ensures that if Project Network Isolation is turned on (and Network Policies are used) that the Release Namespace is already configured to allow Pods to reach out into all namespaces (not just Project namespaces) since that's how all system project namespaces are configured.

However, in case a Rancher user would like to place the Project Release Namespaces outside the System project (e.g. to be able to set resource quotas across a dedicated release project) and is in this type of setup, since the Project Release namespaces are deployed with a default network policy allowing no ingress or egress, any action that requires reaching across to project namespaces (e.g. scraping custom metric workloads) will not be allowed.

Describe the solution you'd like

The Helm Chart should automatically create Network Policies allowing pods in the Project Release Namespace to reach out to all pods in any Project Namespace; these network policies should be configurable on a chart level.

Describe alternatives you've considered

Additional context

Should modify drone builds and Helm chart to be able to support deploying the locker on Windows nodes to avoid the Linux-only requirement; should be easily possible since it just involves packaging a Go binary in an image.

Note: this does not have a high ROI since Windows clusters generally have Linux nodes that can run these controllers on them, but it would be nice to have if possible

Same issue as rancher/prometheus-federator#29.

Describe the bug

If a project ID is added to otherSystemProjectLabelValues during a Helm upgrade, any ProjectHelmChart that is already deployed in that project's registration namespace will be left with a status of "Deployed" even though the underlying HelmChart and HelmRelease will be cleaned up.

To Reproduce

1. Deploy Helm Project Operator (ensure that both project-label and system-project-label-value are provided; if using a Rancher 2.6.5+ setup, this should already be the case)
2. Add a ProjectHelmChart to the registration namespace of a Project that you plan to ignore, e.g. one named DoNotMonitorMe
3. Upgrade the Helm Project Operator chart to add the project ID of the project that you plan to ignore (e.g. p-XXXX) to the list of .Values.otherSystemProjectLabelValues

Result
HelmChart and HelmRelease tied to that ProjectHelmChart will be cleaned up, but the status will not be changed.

Expected Result

ProjectHelmChart status should either become empty, take on a newly defined status like CannotDeployInSystemProject, or take on the existing status of UnableToCreateHelmRelease on being targeted within a system project.

Screenshots

Additional context

Follow the changes added in rancher/helm-locker@34be7c6 in order to introduce a managedBy annotation that will allow Helm Project Operators to claim ProjectHelmCharts that they are managing based on the Helm chart's release name.

This will allow a single Project Operator (e.g. prometheus-federator) to be deployed multiple times in the same cluster under different names (e.g. org-a-federator, org-b-federator, etc.) instead of forcing a single Project Operator to manage all Projects in the cluster.

This should be done alongside adding support for specifying an allow-list of Project IDs, which would allow the operators to configure a logical separation of which namespaces they operate on.

Testing if this works

Even if the embedded helm controller is disabled, the Helm Job Image should still be overridden to ensure that the image deployed into the HelmChart CR by a Helm Project Operator contains private registry details.

Currently, this means that an airgapped RKE2 cluster will not have this image overridden on deployment by the operator

Supplying .Values.global.imagePullSecrets is broken since arbitrary keys being added after imagePullSecrets are defined:

arvindiyengar: ~/Rancher/helm-project-operator/src/github.com/aiyengar2/helm-project-operator 
$ helm template --set 'global.imagePullSecrets[0].name=mySecret' helm-project-operator charts/helm-project-operator | kubeconform --strict
stdin - ServiceAccount helm-project-operator is invalid: For field imagePullSecrets.0: Additional property chart is not allowed - For field imagePullSecrets.0: Additional property heritage is not allowed - For field imagePullSecrets.0: Additional property release is not allowed - For field imagePullSecrets.0: Additional property app.kubernetes.io/instance is not allowed - For field imagePullSecrets.0: Additional property app.kubernetes.io/managed-by is not allowed - For field imagePullSecrets.0: Additional property app.kubernetes.io/part-of is not allowed - For field imagePullSecrets.0: Additional property app.kubernetes.io/version is not allowed