crossplane-contrib/provider-helm

Crossplane Helm Provider

provider-helm

provider-helm is a Crossplane Provider that enables deployment and management of Helm Releases on Kubernetes clusters typically provisioned by Crossplane, and has the following functionality:

• A Release resource type to manage Helm Releases.
• A managed resource controller that reconciles Release objects and manages Helm releases.

Install

If you would like to install provider-helm without modifications, you may do so using the Crossplane CLI in a Kubernetes cluster where Crossplane is installed:

crossplane xpkg install provider xpkg.upbound.io/crossplane-contrib/provider-helm:v0.17.0

Then you will need to create a ProviderConfig that specifies the credentials to connect to the Kubernetes API. This is commonly done within a Composition by storing a kubeconfig into a secret that the ProviderConfig references. An example of this approach can be found in configuration-aws-eks.

Quick start

An alternative, that will get you started quickly, is to reuse existing credentials from within the control plane.

First install provider-helm with additional configuration to bind its service account to an existing role in the cluster:

kubectl apply -f ./examples/provider-config/provider-incluster.yaml

Then simply create a ProviderConfig that uses an InjectedIdentity source:

kubectl apply -f ./examples/provider-config/provider-config-incluster.yaml

provider-helm will then be installed and ready to use within the cluster. You can now create Release resources, such as sample release.yaml.

kubectl create -f examples/sample/release.yaml

Design

See the design document.

Developing locally

Pre-requisite: A Kubernetes cluster with Crossplane installed

To run the provider-helm controller against your existing local cluster, simply run:

make run

Since the controller is running outside of the local cluster, you need to make the API server accessible (on a separate terminal):

sudo kubectl proxy --port=8081

Then we must prepare a ProviderConfig for the local cluster (assuming you are using kind for local development):

KUBECONFIG=$(kind get kubeconfig | sed -e 's|server:\s*.*$|server: http://localhost:8081|g')
kubectl -n crossplane-system create secret generic cluster-config --from-literal=kubeconfig="${KUBECONFIG}" 
kubectl apply -f examples/provider-config/provider-config-with-secret.yaml

Now you can create Release resources with this ProviderConfig, for example sample release.yaml.

kubectl create -f examples/sample/release.yaml

provider-helm's Issues

releases not deleting when in composition with a gke cluster

What happened?

When i have a XR and the composition contains a cluster (gke), helm provider config and helm charts, when i delete the XR it should remove all releases (releases.helm.crossplane.io).

it starts deleting the cluster or the kubeconfig secret before helm provider has a chance to clean up. Error message failed to extract kubeconfig: cannot get credentials secret: Secret "f70c8c2a-4be7-46eb-8487-a78333a6dd02-gke-cluster" not found

How can we reproduce it?

Create a gke cluster, nodepool, helm-provider-config and some helm charts into the composition of an XR. Then delete the XR.

What environment did it happen in?

Crossplane version: 1.5.0

Release resource fails to determine status of the Helm release

What happened?

The Release resource never gets into any status.
The .status field is even present when I run kubectl get release my-release -o yaml

 kubectl get release helm-test
NAME        CHART                             VERSION   SYNCED    READY     STATE     REVISION   DESCRIPTION   AGE
helm-test   crossplane-irsa-service-account   0.1.3                                                            16m

How can we reproduce it?

My Helm chart is only creating a single Kubernetes resource, a ServiceAccount.
I can see that the service account resource is created as expected.
The Helm release itself is in status deployed.

helm3 ls -n johns-space
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                                   APP VERSION
helm-test       johns-space     1               2021-07-21 10:20:18.166948602 +0000 UTC deployed        crossplane-irsa-service-account-0.1.3   1.0.0

kubectl get release helm-test -o yaml:

apiVersion: helm.crossplane.io/v1beta1
kind: Release
metadata:
  annotations:
    crossplane.io/external-name: helm-test
    kubectl.kubernetes.io/last-applied-configuration: |
      ...
  creationTimestamp: 2021-07-21T10:20:17Z
  finalizers:
  - finalizer.managedresource.crossplane.io
  generation: 2
  managedFields:
  - apiVersion: helm.crossplane.io/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          f:crossplane.io/external-name: {}
        f:finalizers:
          .: {}
          v:"finalizer.managedresource.crossplane.io": {}
      f:status:
        .: {}
        f:atProvider: {}
    manager: crossplane-helm-provider
    operation: Update
    time: 2021-07-21T10:20:17Z
  - apiVersion: helm.crossplane.io/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:kubectl.kubernetes.io/last-applied-configuration: {}
      f:spec:
        .: {}
        f:forProvider:
          .: {}
          f:chart:
            .: {}
            f:name: {}
            f:pullSecretRef:
              .: {}
              f:name: {}
              f:namespace: {}
            f:repository: {}
            f:version: {}
          f:namespace: {}
          f:skipCreateNamespace: {}
          f:values:
            .: {}
            f:serviceAccount: {}
        f:providerConfigRef:
          .: {}
          f:name: {}
    manager: kubectl.exe
    operation: Update
    time: 2021-07-21T10:20:17Z
  name: helm-test
  resourceVersion: "57346645"
  uid: 3cfc444b-64c4-43e9-8f52-ac234393b37d
spec:
  forProvider:
    chart:
      name: crossplane-irsa-service-account
      pullSecretRef:
        name: artifactory-basic-auth
        namespace: crossplane-system
      repository: https://my-artifactory.com/artifactory/helm-virtual
      version: 0.1.3
    namespace: johns-space
    skipCreateNamespace: true
    values:
      serviceAccount:
        annotations:
          eks.amazonaws.com/role-arn: test-annotation
        name: my-sa
  providerConfigRef:
    name: helm-provider

kubectl describe release helm-test:

Name:         helm-test
Namespace:
Labels:       <none>
Annotations:  crossplane.io/external-name=helm-test
              kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"helm.crossplane.io/v1beta1","kind":"Release","metadata":{"annotations":{},"name":"helm-test","namespace":""},"spec":{"forProvider":{"cha...
API Version:  helm.crossplane.io/v1beta1
Kind:         Release
Metadata:
  Creation Timestamp:  2021-07-21T10:20:17Z
  Finalizers:
    finalizer.managedresource.crossplane.io
  Generation:  2
  Managed Fields:
    API Version:  helm.crossplane.io/v1beta1
    Fields Type:  FieldsV1
    Fields V 1:
      F : Metadata:
        F : Annotations:
          F : Crossplane . Io / External - Name:
        F : Finalizers:
          .:
          V :" Finalizer . Managedresource . Crossplane . Io ":
      F : Status:
        .:
        F : At Provider:
    Manager:      crossplane-helm-provider
    Operation:    Update
    Time:         2021-07-21T10:20:17Z
    API Version:  helm.crossplane.io/v1beta1
    Fields Type:  FieldsV1
    Fields V 1:
      F : Metadata:
        F : Annotations:
          .:
          F : Kubectl . Kubernetes . Io / Last - Applied - Configuration:
      F : Spec:
        .:
        F : For Provider:
          .:
          F : Chart:
            .:
            F : Name:
            F : Pull Secret Ref:
              .:
              F : Name:
              F : Namespace:
            F : Repository:
            F : Version:
          F : Namespace:
          F : Skip Create Namespace:
          F : Values:
            .:
            F : Service Account:
        F : Provider Config Ref:
          .:
          F : Name:
    Manager:         kubectl.exe
    Operation:       Update
    Time:            2021-07-21T10:20:17Z
  Resource Version:  57346645
  UID:               3cfc444b-64c4-43e9-8f52-ac234393b37d
Spec:
  For Provider:
    Chart:
      Name:  crossplane-irsa-service-account
      Pull Secret Ref:
        Name:               artifactory-basic-auth
        Namespace:          crossplane-system
      Repository:           https://my-artifactory.com/artifactory/helm-virtual
      Version:              0.1.3
    Namespace:              johns-space
    Skip Create Namespace:  true
    Values:
      Service Account:
        Annotations:
          Eks . Amazonaws . Com / Role - Arn:  test-annotation
        Name:                                  my-sa
  Provider Config Ref:
    Name:  helm-provider
Events:
  Type    Reason                   Age   From                                Message
  ----    ------                   ----  ----                                -------
  Normal  CreatedExternalResource  12m   managed/release.helm.crossplane.io  Successfully requested creation of external resource

What environment did it happen in?

Crossplane version: crossplane/provider-helm:v0.7.2 and crossplane/crossplane:v1.3.0

Release in Ready state before connection details are available

What happened?

Using the connectionDetails feature (#73) we read the IP of a LoadBalancer service. Unfortunately the Release resource goes to a ready state before the info was read and therefore the connection detail is missing.

How can we reproduce it?

Create a Release which reads the IP of a service:

connectionDetails:
  - apiVersion: v1
    fieldPath: status.loadBalancer.ingress[0].ip
    kind: Service
    name: haproxy
    namespace: b6d9f1ac-d636-44df-a538-5d0cc2a12e9b
    toConnectionSecretKey: endpoint

What environment did it happen in?

Crossplane version: v1.1.0
provider-helm version: v0.5.0

Asynchronous deployment of helm releases

What problem are you facing?

Currently, install and upgrade calls using helm go client is blocking which means, reconcile loop is being blocked until deployment is done. Since we don't set wait (related), this is fine if chart does not contain hooks. However, with hooks we encounter problems like this.

How could Crossplane help solve your problem?

We need to make this action asynchronous somehow.

Support helm dependency

In Crossplane (and specifically for provider-helm), having a 1-to-1 mapping between a Managed resource and external resource is the preferred approach.

With provider-helm right now, it is possible to install each chart with a helm release resource but we would need to handle dependencies in an upper layer, i.e. In a composition by proper ordering.

However, given helm implicitly handles the dependency management when we install one release, this should still be doable in provider-helm I guess.

Helm wait option

Consider a Helm-specific Provider(Config) resource

Currently this provider takes a dependency on crossplane/crossplane for its Kubernetes Provider type. I believe that type was originally introduced for use by the Rook provider. We're repositioning these types as ProviderConfig, i.e. "provider configurations". In this case that would be a configuration for the Helm provider.

I suggest we have this provider define its own Helm-specific ProviderConfig, which would in practice be identical to the Kubernetes ProviderConfig.

Some Charts have unexpected names

What happened?

I attempted to install the strimzi operator using the Helm Release from Crossplane. I get the following error when crossplane attempts to install the chart:

   - lastTransitionTime: '2021-08-27T15:55:40Z'
      message: >-
        create failed: failed to install release: failed to load chart: stat
        /tmp/charts/strimzi-kafka-operator-0.25.0.tgz: no such file or directory
      reason: ReconcileError
      status: 'False'
      type: Synced

Aaron Eaton helped me on Slack find the real problem.
He discovered the strimzi chart;

• creates a file named: strimzi-kafka-operator-helm-3-chart-0.25.0.tgz
• however provider-helm is expecting strimzi-kafka-operator-0.25.0.tgz

He also discovered a workaround where you can set the spec.forProvider.chart.url directly to the source, I have this commented out in the snippet below.

How can we reproduce it?

apiVersion: helm.crossplane.io/v1beta1
kind: Release
metadata:
  name: kafka-operator
spec:
  forProvider:
    chart:
      name: strimzi-kafka-operator
      repository: https://strimzi.io/charts
      # use url instead of repository as a workaround
      # url: https://github.com/strimzi/strimzi-kafka-operator/releases/download/0.25.0/strimzi-kafka-operator-helm-3-chart-0.25.0.tgz
      version: 0.25.0
    namespace: strimzi
    skipCreateNamespace: false
    values:
      watchAnyNamespace: true

What environment did it happen in?

Crossplane version: 1.3.0
Helm Provider version: v0.9.0-rc

Release stops retrying to connect

What happened?

A Release object seems to stop trying to connect if it is unable to do so in the first ~3 minutes. Should it not continue to retry connecting continually after that?

Note in the following status and events, we haven't retried to connect in 51 minutes:

Status:
  At Provider:
  Conditions:
    Last Transition Time:  2020-12-29T22:07:14Z
    Message:               connect failed: cannot create new Kubernetes client: cannot create Kubernetes client: Get "https://35.236.80.135/api?timeout=32s": dial tcp 35.236.80.135:443: connect: connection refused
    Reason:                ReconcileError
    Status:                False
    Type:                  Synced
Events:
  Type     Reason                   Age                From                                Message
  ----     ------                   ----               ----                                -------
  Warning  CannotConnectToProvider  54m (x2 over 54m)  managed/release.helm.crossplane.io  provider could not be retrieved: ProviderConfig.helm.crossplane.io "multik8s-cluster-gcp" not found
  Warning  CannotConnectToProvider  52m (x5 over 54m)  managed/release.helm.crossplane.io  cannot create new Kubernetes client: cannot create Kubernetes client: host must be a URL or a host:port pair: "https://"
  Warning  CannotConnectToProvider  51m                managed/release.helm.crossplane.io  cannot create new Kubernetes client: cannot create Kubernetes client: Get "https://35.236.80.135/api?timeout=32s": dial tcp 35.236.80.135:443: i/o timeout
  Warning  CannotConnectToProvider  51m (x2 over 51m)  managed/release.helm.crossplane.io  cannot create new Kubernetes client: cannot create Kubernetes client: Get "https://35.236.80.135/api?timeout=32s": dial tcp 35.236.80.135:443: connect: connection refused

The full output of kubectl describe releases can be found in the following gist: https://gist.github.com/jbw976/f3507bfeb78ecceb4cd9c2b58cce6e94

Other observations to note:

• The ProviderConfig and its referenced secret seem OK to me, I was able to use the kubeconfig field of the secret to manually connect to the cluster OK.
• The creation of the Release object is 2020-12-29T22:04:14Z and the last transition time for the "connect failed" status is 2020-12-29T22:07:14Z, so about 3 minutes after creation

What environment did it happen in?

crossplane:v1.0.0, provider-helm:v0.5.0

Getting connection detail from manually generated secret

What problem are you facing?

I can reference a secret that is generated by provider-helm, like the following example sited from example. But if that secret is generated manually, it can't be referenced, the generated credential would be empty.

    - apiVersion: v1
      kind: Secret
      name: wordpress-example
      namespace: crossplane-svc
      fieldPath: data.wordpress-password
      toConnectionSecretKey: password

How could Crossplane help solve your problem?

Is there any chance we can reference secrets that are not generated by provider-helm? (or any workarounds?) There's scenarios where we have to generate certs manually, and deliver it to end application via crossplane. Thanks!

Need a way to read status of a Kubernetes resource deployed with provider-helm

I have a composition which includes a managed k8s cluster, a managed db and a helm release which deploys Wordpress application with a new type WordpressCluster.

Right now, once composite resource is ready, I need to connect to remote k8s cluster and read status of LoadBalancer type service to get the IP address of wordpress endpoint. I would like my composite resource to report address of wordpress in its status.

To achieve this, we need a way to read LoadBalancer IP in remote cluster, in addition to composition to support reflecting status of composed resources to composite.

Increase test coverage by adding unit tests

Setting number with "Set" (e.g. port) causes repeating "helm upgrades"

reflect.DeepEqual here decides user config and existing config are different since variable set as number with "set" has different types (int64 vs float64)

Support Helm3 OCI Charts

What problem are you facing?

I've been using Helm3 OCI based charts via GitLab container registry due to ease of use, but OCI based charts are not currently supported by provider-helm.

How could Crossplane help solve your problem?

It would be great if OCI based charts could be supported as this slightly lowers the barrier to entry due to not having to run a Helm repo (peak laziness on my behalf!)

Thoughts:

• How to discern between a normal and an OCI based chart install (Maybe a new Type field which defaults to existing behaviour?)
• How to auth with OCI registry (looks like secret already has a username and password so guessing just calling a different auth method)

I'm happy to look at implementing this if the time is right and we can solidify any additions to the API format.

Trigger helm release upgrade when PatchesFrom are changed

In PatchesFrom we don't detect changes from the related configmaps and secrets.

We need to detect if a change has occurred and trigger a helm upgrade per the design triggering-an-upgrade

Release resource not updated after manual change

What happened?

If a resource that is part of a release is edited manually (i.e. via kubectl edit), the controller does not update the release during the next reconcile. If the release is updated manually via helm upgrade the resource is changed.

The issue is most likely that provider-helm only compares the release manifests to determine if changes are necessary. This would be similar to helm diff plugin which does not detect any changes as well.

Is this intended behavior? If yes, is there some way to circumvent this?

How can we reproduce it?

1. Create a simple helm chart that deploys a single resource, i.e a ConfigMap and deploy it via a managed simple Release:

apiVersion: v1
kind: ConfigMap
metadata:
    name: {{ .Release.Name }}-config
data:
    hello: world

2. Edit the resource manually via kubectl edit.
3. Wait for the next reconcile which will not trigger an update. helm diff will not show any changes as well.

What environment did it happen in?

Provider version: v0.7.0

Release stuck in CannotUpdateExternalResource

What happened?

I'm trying to create a CompositeCluster via Upbound Cloud using the AWS reference platform v0.0.4, which I think corresponds roughly to https://github.com/upbound/platform-ref-aws/tree/fee50c794da296e832fb7a80bdee8cff508aac96. It seems like the Helm release created by this platform is stuck permanently in CannotUpdateExternalResource:

Name:         clustor-xnkq2-ftz94
Namespace:    
Labels:       crossplane.io/claim-name=clustor
              crossplane.io/claim-namespace=it
              crossplane.io/composite=clustor-xnkq2
Annotations:  crossplane.io/external-name: clustor-xnkq2-ftz94
API Version:  helm.crossplane.io/v1alpha1
Kind:         Release
Metadata:
  Creation Timestamp:  2020-11-02T23:15:54Z
  Finalizers:
    finalizer.managedresource.crossplane.io
  Generate Name:  clustor-xnkq2-
  Generation:     2
  Owner References:
    API Version:     aws.platformref.crossplane.io/v1alpha1
    Controller:      true
    Kind:            Services
    Name:            clustor-xnkq2-gv4h2
    UID:             f003da91-c3b0-43b8-ae5d-db91cf147131
  Resource Version:  881946
  Self Link:         /apis/helm.crossplane.io/v1alpha1/releases/clustor-xnkq2-ftz94
  UID:               1796dea7-2826-48f4-abff-32467441192f
Spec:
  For Provider:
    Chart:
      Name:  kube-prometheus-stack
      Pull Secret Ref:
        Name:       
        Namespace:  
      Repository:   https://prometheus-community.github.io/helm-charts
      Version:      10.1.0
    Namespace:      operators
    Values:
  Provider Config Ref:
    Name:  clustor
Status:
  At Provider:
    Release Description:  Initial install underway
    Revision:             1
    State:                pending-install
  Conditions:
    Last Transition Time:  2020-11-02T23:28:10Z
    Message:               update failed: failed to upgrade release: "clustor-xnkq2-ftz94" has no deployed releases
    Reason:                ReconcileError
    Status:                False
    Type:                  Synced
    Last Transition Time:  2020-11-02T23:27:48Z
    Reason:                Unavailable
    Status:                False
    Type:                  Ready
Events:
  Type     Reason                        Age                   From                                Message
  ----     ------                        ----                  ----                                -------
  Warning  CannotConnectToProvider       25m (x2 over 25m)     managed/release.helm.crossplane.io  provider could not be retrieved: ProviderConfig.helm.crossplane.io "clustor" not found
  Warning  CannotConnectToProvider       16m (x20 over 25m)    managed/release.helm.crossplane.io  secret referred in provider could not be retrieved: secret data is nil
  Warning  CannotUpdateExternalResource  9m7s (x9 over 13m)    managed/release.helm.crossplane.io  failed to upgrade release: "clustor-xnkq2-ftz94" has no deployed releases
  Warning  CannotUpdateExternalResource  5m2s (x5 over 7m27s)  managed/release.helm.crossplane.io  failed to upgrade release: "clustor-xnkq2-ftz94" has no deployed releases
  Warning  CannotUpdateExternalResource  7s (x6 over 3m7s)     managed/release.helm.crossplane.io  failed to upgrade release: "clustor-xnkq2-ftz94" has no deployed releases

How can we reproduce it?

Use Upbound Cloud to create a CompositeNetwork, then a CompositeCluster.

What environment did it happen in?

kubectl crossplane install provider crossplane/provider-helm:v0.3.5

Implement helm atomic

What problem are you facing?

Release deployment fails due to external dependencies, but would be able to deploy a couple of seconds later.
provider-helm does not retry to upgrade the release because the current release description matches the configured release resource.

Atomic would ensure that only a successful deployment is considered deployed.

How could Crossplane help solve your problem?

Crossplane reconcile would ensure deployments are retried until a successful deployment.

Potentially a retryBackoff would be required.

provider-helm hides providerconfigs

What happened?

Installing crossplane/provider-helm:master hides the created providerconfigs

How can we reproduce it?

kubectl crossplane install provider crossplane/provider-gcp:master
kubectl crossplane install provider crossplane/provider-helm:master

echo """
apiVersion: gcp.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  projectID: project_id
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: gcp-creds
      key: credentials
""" | kubectl create -f -

kubectl get providerconfig default
Error from server (NotFound): providerconfigs.helm.crossplane.io "default" not found

Strangely, the rest continues to work and the default providerconfig can be used when creating infra.

If you skip kubectl crossplane install provider crossplane/provider-helm:master, the providerconfig is found.

What environment did it happen in?

kubectl crossplane -v
v1.2.1

Post Rendering Patches

It should be possible to provide post rendering patches which will make last mile configurations using
post rendering option of Helm. spec.forProvider.patchesFrom
array will be used to specify patch definitions satisfying kustomizes patchTransformer interface.

Example:

patches:
- patch: |-
    - op: replace
      path: /some/existing/path
      value: new value
  target:
    kind: MyKind
    labelSelector: "env=dev"
- patch: |-
    - op: add
      path: /spec/template/spec/nodeSelector
      value:
        node.size: really-big
        aws.az: us-west-2a
  target:
    kind: Deployment
    labelSelector: "env=dev"

More context: crossplane/crossplane#1642 (comment)
Design doc: https://github.com/crossplane/crossplane/blob/master/design/one-pager-helm-provider.md#crossplane-helm-provider

secretKeyRef overwrites key name

What happened?

Scenario: I'm using the provider-helm as a workaround (until crossplane-contrib/provider-kubernetes#21 is merged) to create a secret on a remote cluster. This secret is intended for use by flux, and takes in the flux-sync data keys as inputs to a very basic helm chart. Unfortunately, the key fields aren't being honored in the helm template, and instead, the valueFrom reference appears to overwrite the key name. This is a problem when the key name needs to be "identity.pub", but that type of naming is not possible (as far as I know) when setting the helm values (as it would assume that .pub is a child value of identity).

How can we reproduce it?

• Sample helm chart template:

apiVersion: v1
kind: Secret
metadata:
  labels:
    app.kubernetes.io/instance: {{ .Release.Namespace | quote }}
    app.kubernetes.io/managed-by: {{ .Release.Service | quote }}
    helm.sh/chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
  name: {{ .Values.secret.name }}
  namespace:  {{ .Values.secret.namespace }}
type: Opaque
data:
  identity: {{ .Values.secret.data.identity | toString | b64enc | quote }}
  identity.pub: {{ .Values.secret.data.identity_pub | toString | b64enc | quote }}
  known_hosts: {{ .Values.secret.data.known_hosts | toString | b64enc | quote }}

• Sample values.yaml

secret:
  name: "secret"
  namespace: "default"
  data:
    identity: ""
    identity_pub: ""
    known_hosts: ""

Sample Crossplane Helm Resource

---
apiVersion: helm.crossplane.io/v1beta1
kind: Release
metadata:
  name: secret-only
spec:
# rollbackLimit: 3
  forProvider:
    chart:
      name: secret-only
      repository: https://stewartshea.github.io/helm-charts/
    namespace: flux-system
    values:
      secret: 
        name: flux-sync
        namespace: flux-system 
    set: 
    - name: secret.data.identity
      valueFrom:     
        secretKeyRef:
          name: flux-sync
          namespace: flux-system
          key: identity
    - name: secret.data.identity_pub
      valueFrom:     
        secretKeyRef:
          name: flux-sync
          namespace: flux-system
          key: identity.pub  
    - name: secret.data.known_hosts
      valueFrom:     
        secretKeyRef:
          name: flux-sync
          namespace: flux-system
          key: known_hosts   
  providerConfigRef:
    name: providerconfig-helm

The above combination will create the secret on the remote cluster, but with a key titled identity_pub instead of "identity.pub" as specified by the helm chart. This could very well be a mistake on my end as I've not had to author a helm chart before but after quite a bit of testing it feels like crossplane-helm is just overwriting the key. I've changed the name from secret.data.identity_pub to other names, and indeed the key always matches what is in that field.

What environment did it happen in?

Crossplane version:

• crossplane-1.6.1
• crossplane/provider-helm:v0.9.0
• GKE - v1.21.5-gke.1302

Support GKE OAuth Authorization

What problem are you facing?

https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication

As far as I can tell the only way to get a GKE cluster to produce a kubeconfig that can be used by provider-helm (i.e. a kubeconfig that authenticates as cluster-admin) is to enable basic master auth, support for which was removed in v1.19. GKE can generate a client certificate instead, but that is also deprecated and doesn't actually have permissions to do anything useful per kubernetes/kubernetes#65400.

I believe this means that provider-helm can't be used to release charts to a GKE 1.19 or above cluster created via provider-gcp.

How could Crossplane help solve your problem?

I believe it may be possible to integrate with GKE's native OAuth support somehow? Crossplane can create a GCP ServiceAccount - perhaps we could have that write its OAuth token to a connection secret that this provider could consume? I believe based on very cursory research that that token can be used to authenticate to the API server, and that the resulting user will be granted RBAC access corresponding to their GCP IAM permissions.

Release resource does not reconcile when deleting helm release.

What happened?

Release Does not reconcile after manually deleting helm release using helm cli

How can we reproduce it?

Install helm-provider:master and use providerconfig in-cluster.
Install release resource.
then delete the helm release using helm cli.
at least there's to much downtime after manually deleting the helm release(sometime the Release Object recreate the helm release)
But mostly, the release Object does not reconcile!

What environment did it happen in?

Crossplane version: 1.3.0
Kubernetes version: v1.21.1
Kind Cluster.

k get releases.helm.crossplane.io
NAME         CHART           VERSION   SYNCED   READY   STATE      REVISION   DESCRIPTION        AGE
opendistro   opendistro-es   1.13.3    True     True    deployed   1          Install complete   15m

Status:
  At Provider:
    Release Description:  Install complete
    Revision:             1
    State:                deployed
  Conditions:
    Last Transition Time:  2021-07-16T15:32:46Z
    Reason:                Available
    Status:                True
    Type:                  Ready
    Last Transition Time:  2021-07-16T15:32:45Z
    Reason:                ReconcileSuccess
    Status:                True
    Type:                  Synced
  Synced:                  true
Events:
  Type    Reason                   Age    From                                Message
  ----    ------                   ----   ----                                -------
  Normal  UpdatedExternalResource  16m    managed/release.helm.crossplane.io  Successfully requested update of external resource
  Normal  CreatedExternalResource  6m18s  managed/release.helm.crossplane.io  Successfully requested creation of external resource

Optional rollback in case of failure

Optional Namespace Creation

What problem are you facing?

provider-helm tries to create a namespace even if it already exists. In general this is fine because it fails gracefully and continues with the rest of the execution [1], but it still requires namespace creation RBAC permissions.
In some cases I only want to deploy to existing namespaces and don't want to grant this permission to provider-helm.

How could Crossplane help solve your problem?

Currently namespace creation is hardcoded here:

provider-helm/pkg/clients/helm/client.go

Line 103 in 94c5b9a

ic.CreateNamespace = true

I see two options how to solve this:

1. Introduce an option to configure if a release should try to create the namespace
2. Let the provider figure out if the namespace creation is actually necessary beforehand

[1] https://github.com/helm/helm/blob/master/pkg/action/install.go#L307

In cluster provisioning with RBAC

What problem are you facing?

It is very possible to use provider-helm for in-cluster provisioning as a regular helm controller instead of deploying into external cluster. Today, this could be realized by putting kubeconfig of the local cluster into a secret and creating a ProviderConfig pointing to that secret. However, this approach is not the expected way to communicate/authenticate cluster api from inside the cluster.

How could Crossplane help solve your problem?

Is should be possible to do in cluster provisioning by relying on RBAC.
This could be achievable by introducing a new credentials.source, e.g. "InCluster" and configuring provider controller with proper service account during deployment.

Auto upgrade to latest version in the repo

Installing Helm release from URL causes upgrade error

What happened?

When creating a new Release with a URL in the name field, I receive a no such file or directory error message due to assumptions about release filenames.

How can we reproduce it?

Install a helm chart from a URL:

 apiVersion: helm.crossplane.io/v1beta1
 kind: Release
 metadata:
   name: test
   namespace: default
 spec:
   providerConfigRef:
     name: helm-provider
   forProvider:
     namespace: default
     chart:
       name: https://gitlab...../api/v4/projects/..../packages/generic/helm-chart/0.25.0/chart-bleeding.tgz?private_token=....
       repository: ""
       version: ""

Produces following log messages on Release:

  Normal   CreatedExternalResource       7s               managed/release.helm.crossplane.io  Successfully requested creation of external resource
  Normal   UpdatedExternalResource       5s               managed/release.helm.crossplane.io  Successfully requested update of external resource
  Warning  CannotUpdateExternalResource  4s (x3 over 7s)  managed/release.helm.crossplane.io  failed to upgrade release: failed to load chart: stat /tmp/charts/https:/gitlab....?private_token=....-0.25.0.tgz: no such file or directory

Note that the chart runs successfully first time and creates the relevant resources. It looks like this may be caused by late init modifying the version field from the empty string, causing different behaviour.

What environment did it happen in?

Crossplane / Provider-helm version: master

Issues

2 Problems here - first is that repository and version are not optional in the Release API, but they are optional when it comes to calling Helm, because Helm supports installing a chart .tar.gz directly from URL. Setting them both to empty strings sorta works but...

Second is that the chartFilePath logic in PullAndLoadChart (Helm client) uses the name field incorrectly if a version is set.

The version is late-inited from the chart itself so it is not possible to avoid this error by setting an empty version string.

It also makes an assumption about the filename format (${name}-${version}.tgz) of the Helm chart in a repository which doesn't necessarily hold true - AIUI, a Helm repository can set whatever filename it likes for a chart version entry, and I think the name in the repository is what is used when downloading.

Fix?

• repository and version should be optional (string pointer, omitempty, // +optional)
• Chart filename logic needs expanding, taking into account that name can contain a URL, an absolute path or a path within a repository.

Happy to look at PR-ing a fix for these but I don't have a clear view on what the 'Chart name logic' behaviour should be. I suspect it needs to support something similar to ResolveChartVersion in Helm itself.

release with failed hook shows as deployed

Created a release with pre-install hook with a bogus image. The pre-install hook pod failed with imagepullbackoff. However this did not stop the deploy of release and the release eventually released ready status. It did log an error in the release and prevent the post-hook install

NAME READY STATUS RESTARTS AGE
pod/pre-install-job-wjjv5 0/1 ImagePullBackOff 0 5m34s
pod/demoapp-staging-566d89d94b-t2666 1/1 Running 0 31s
pod/demoapp-staging-566d89d94b-f6wp6 1/1 Running 0 15s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/demoapp-staging ClusterIP 10.100.77.77 80/TCP 31s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/demoapp-staging 2/2 2 2 32s

NAME DESIRED CURRENT READY AGE
replicaset.apps/demoapp-staging-566d89d94b 2 2 2 32s

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
horizontalpodautoscaler.autoscaling/demoapp-staging Deployment/demoapp-staging /50% 2 10 2 32s

NAME COMPLETIONS DURATION AGE
job.batch/pre-install-job 0/1 5m35s 5m35s

Status:
At Provider:
Release Description: Upgrade complete
Revision: 8
State: deployed
Conditions:
Last Transition Time: 2022-01-24T21:07:21Z
Reason: Available
Status: True
Type: Ready
Last Transition Time: 2022-01-24T21:07:21Z
Reason: ReconcileSuccess
Status: True
Type: Synced
Synced: true
Events:
Type Reason Age From Message

---

Warning CannotCreateExternalResource 3m26s managed/release.helm.crossplane.io failed to install release: failed pre-install: timed out waiting for the condition
Warning CannotUpdateExternalResource 2m55s managed/release.helm.crossplane.io failed to upgrade release: failed to update chart spec with the latest version: Operation cannot be fulfilled on releases.helm.crossplane.io "fl-sampleteam-myapp-myapp-myapp-target-cluster": the object has been modified; please apply your changes to the latest version and try again
Normal UpdatedExternalResource 24s (x7 over 3m22s) managed/release.helm.crossplane.io Successfully requested update of external resource

How can we reproduce it?

What environment did it happen in?

Crossplane version: 1.6.1

• Cloud provider or hardware configuration: AWS
• Kubernetes version client:1.22, server:1.19
• Kubernetes distribution EKS
• OS (e.g. from /etc/os-release)
• Kernel (e.g. uname -a)

Provide the ability to combine multiple references when setting a single helm value

What problem are you facing?

Using the aws provider and creating a redis server I am unable to install the chart goharbor (https://helm.goharbor.io) using the helm provider since I am unable to provide a value for "redis.external.addr" which requires the form :. The connection details which are written by the aws provider give the host and port as separate keys however since this chart combines them I unable to easily use the helm provider. The helm provider provides a direct replacement value substitution but no transformation or templating.

How could Crossplane help solve your problem?

Some kind of basic templating would be really helpful. Given an array of references (config or secrets) and a template "%s:%s this issue could be easily addressed.

Expose Ready Condition

What problem are you facing?

Currently the Release CRD exposes a Synced condition, which does not work well with the default readinessChecks of a Composition since it's expecting a Ready condition instead.
A custom readinessCheck would be required for each Release in a Composition just to use the Synced string.

How could Crossplane help solve your problem?

Either change the condition from Synced to Ready or add an additional condition of type Ready.

`make run` strips the crds files

Trying to setup a dev env as documented on the README.md, I make run, and it fails with error validating "package/crds/helm.crossplane.io_providerconfigs.yamlwhich is logical as the CRDs files have been stripped.

git diff
diff --git a/package/crds/helm.crossplane.io_providerconfigs.yaml b/package/crds/helm.crossplane.io_providerconfigs.yaml
index 46db82d..3fdd31c 100644
--- a/package/crds/helm.crossplane.io_providerconfigs.yaml
+++ b/package/crds/helm.crossplane.io_providerconfigs.yaml
@@ -1,7 +1,3 @@
-apiVersion: apiextensions.k8s.io/v1
-kind: CustomResourceDefinition
-metadata:
-  annotations:
     controller-gen.kubebuilder.io/version: v0.3.0
   creationTimestamp: null
   name: providerconfigs.helm.crossplane.io
diff --git a/package/crds/helm.crossplane.io_providerconfigusages.yaml b/package/crds/helm.crossplane.io_providerconfigusages.yaml
index a6b81c3..58ca59d 100644

Support EKS IAM authentication

What problem are you facing?

EKS only supports IAM based authentication, unless you go a roundabout way and use an OIDC provider. This means that the helm provider is not able to interact with Crossplane created EKS clusters, since the kubeconfig that EKS uses depends on the aws cli or aws-iam-authenticator.

Some background on EKS auth: https://docs.aws.amazon.com/eks/latest/userguide/managing-auth.html

How could Crossplane help solve your problem?

Ideally, we would be able to use the helm provider targeting EKS clusters. My org is working on a Crossplane proof of concept and would like to demonstrate that we can use it to completely manage all the resources we create for customers, which includes both creating the clusters (creating an EKS cluster w/ the aws-provider) and then releasing our software to said clusters (with the helm-provider).

Skip CRDs in Release

What problem are you facing?

I am using a chart which does not use the full CRD specs for the project. I want the full ones but I am unable to skip what the chart is creating. Then the release will reconcile and override the full ones I applied.

How could Crossplane help solve your problem?

Add an option to the Release kind to skip crds.
Like this: spec.forProvider.skipCRDs: true
This is an option on Helm itself with this flag: --skip-crds

Upgrade to latest go helm libraries

What problem are you facing?

With the jupyterhub helm chart, in the absence of some values, the following error is hit `wrong type for value; expected map[string]interface {}; got interface {}``

jupyterhub/zero-to-jupyterhub-k8s#1998 Give more background on this.

For the record, Terraform helm provider was hitting the same problem (see details in the linked issue), and @chrisbulgaria said on jupyterhub/zero-to-jupyterhub-k8s#1998 (comment) ... Think by upgrading to the latest version of some helm go libraries , so...

ValueFrom field does not meet Kubernetes API conventions

The json tag seems to be forgotten as ValueFrom where it should've been valueFrom: https://github.com/crossplane-contrib/provider-helm/blob/d313bcf/apis/v1alpha1/types.go#L56

Release fails when wait is set

What happened?

When creating a release the latest v0.8.0 and the Wait: true flag set, a release will immediately fail with "context deadline exceeded".

2021-08-18T14:02:27.715+0200	DEBUG	helm_provider	creating [5] resource(s)	{"controller": "managed/release.helm.crossplane.io"}
2021-08-18T14:02:27.731+0200	DEBUG	helm_provider	beginning wait for [5 0] resources with timeout of %!v(MISSING)	{"controller": "managed/release.helm.crossplane.io"}
2021-08-18T14:02:27.747+0200	DEBUG	helm_provider	Cannot create external resource	{"controller": "managed/release.helm.crossplane.io", "request": "/promtail-87fd1e0", "uid": "600bcbdc-7294-4869-b475-55d165b426e0", "version": "378", "external-name": "", "error": "failed to install release: context deadline exceeded", "errorVerbose": "context deadline exceeded\nfailed to install release\n [...]"}

The issue seems to be that the provider does not set the timeout flag and combined with helm/helm#9761, this causes the release to fail immediately.

How can we reproduce it?

Create a release with the Wait: true flag.

What environment did it happen in?

Crossplane version: v1.3.0

Parallel processing of multiple helm releases

Processing a Helm Release resource could take some time (pulling chart, installing/upgrading helm release). Since they are independent units, we should be able to process them concurrently without waiting one to complete.

MaxConcurrentReconciles option of controller runtime seems like the solution here which we should configure. We can set a sensible default (e.g. 10) or expose it as a configuration option.

Using Provider Helm with existing Kube Cluster

Hi,
I have an existing Kube Cluster, say A, with operators running on it for various custom resources and a separate cluster, say B, just for crossplane. Is it possible to use provider helm out of the box to provision/manage those arbitrary resources I have installed in cluster A. If it is possible, how can I go about it (a doc, example).
We use crossplane to work with resources in AWS and GCP , so we can use it for kube clusters as well then it would be good.
Thanks

Support semver 'constraint/query' in spec.forProvider.chart.version

What problem are you facing?

Given the following release:

apiVersion: helm.crossplane.io/v1beta1
kind: Release
metadata:
  name: waas-helm-crossplane-release-example-stage-east
spec:
  deletionPolicy: Delete
  forProvider:
    chart:
      name: test
      repository: https://my.artifactory.foo/helmcharts
      version: ~0.1.1

It should respect the ~0.1.1 query and resolve the proper version to use. Right now I get an error like 'create failed: failed to install release: failed to load chart: stat /tmp/charts/test-~0.1.1.tgz: no such file or directory'

How could Crossplane help solve your problem?

It should conform with how the helm cli client resolves this issue.

I'll dig more into how the helm client code and see how they resolve this and perhaps prepare a pullrequest.

Mark Created Namespaces

What problem are you facing?

If a chart is uninstalled, the previously created namespace won't be deleted with it. This might be a good thing because other resources like PVCs are also left in place (if they're created by a StatefulSet for example).
Nevertheless we want to remove these orphaned namespaces at some point.

How could Crossplane help solve your problem?

If a release was deleted and the chart was successfully uninstalled, the provider could add a label & annotation to the namespace:

metadata:
  labels:
    meta.helm.sh/deleted: 'true'
  annotations:
    meta.helm.sh/deletionTimestamp: "2021-01-18T13:25:35Z"

This would help to manually or automatically remove namespaces of uninstalled charts:

kubectl delete ns -l meta.helm.sh/deleted=true

set values from cloudprovider backends SecretManager, ParameterStore ...

What problem are you facing?

set secrets from cloudprovider backends like AWS SecretManager, ParameterStore

How could Crossplane help solve your problem?

we could implement https://github.com/variantdev/vals and can configure values like:

            set: 
              - name: token
                valueFrom: 
                  valRef: 
                    key: ref+awssecrets://myteam/mydoc#/foo/bar

We need to add authentication to provider-helm to grant access in CloudProvider

Create Connection Secrets

What problem are you facing?

Currently there's no way to create a connection secret from a resource provisioned by provider-helm. For example using the MariaDB Chart I'd like to expose the username, password and hostname in a connection secret.

How could Crossplane help solve your problem?

Reading state back from created resources by a Helm chart provider-helm could create a connection secret.
Might be related to crossplane/crossplane#1722 and/or crossplane/crossplane#1603.

Empty version for latest

If no chart version is provided, controller should find the latest version in chart repo and fill the spec.

This does not mean controller should automatically upgrade to a newer version when there is one available later. We should separate these two functionality since auto upgrading to latest version might not be something always desired.

ProviderConfig stuck in deletion

What happened?

I played with the helm-provider and ended up in a place, where I'm unable to kubectl delete providerconfig helm-provider

probably related to #31

Current state of the resource: kubectl get providerconfig helm-provider -o yaml

apiVersion: helm.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"helm.crossplane.io/v1alpha1","kind":"ProviderConfig","metadata":{"annotations":{},"creationTimestamp":"2021-08-13T08:35:56Z","finalizers":["in-use.crossplane.io"],"generation":3,"managedFields":[{"apiVersion":"helm.crossplane.io/v1beta1","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:finalizers":{".":{},"v:\"in-use.crossplane.io\"":{}}},"f:status":{}},"manager":"crossplane-helm-provider","operation":"Update","time":"2021-08-13T08:35:56Z"},{"apiVersion":"helm.crossplane.io/v1beta1","fieldsType":"FieldsV1","fieldsV1":{"f:metadata":{"f:annotations":{".":{},"f:kubectl.kubernetes.io/last-applied-configuration":{}}},"f:spec":{".":{},"f:credentials":{".":{},"f:source":{}}}},"manager":"kubectl-client-side-apply","operation":"Update","time":"2021-08-13T09:07:01Z"}],"name":"helm-provider","selfLink":"/apis/helm.crossplane.io/v1alpha1/providerconfigs/helm-provider","uid":"47364ba1-c693-41b7-b87a-bdc10ce453b6"},"spec":{"credentials":{"source":"InjectedIdentity"}}}
  creationTimestamp: "2021-08-13T08:35:56Z"
  deletionGracePeriodSeconds: 0
  deletionTimestamp: "2021-08-13T08:36:12Z"
  finalizers:
  - in-use.crossplane.io
  generation: 3
  name: helm-provider
  resourceVersion: "524115"
  uid: 47364ba1-c693-41b7-b87a-bdc10ce453b6
spec:
  credentials:
    source: InjectedIdentity
status: {}

How can we reproduce it?

The requested cert-manager helm chart was already installed in the cluster, before creating below resources.

Not sure what order of commands, but I was basically using ~ below:

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: helm-provider
spec:
  package: "crossplane/provider-helm:master"
---
apiVersion: helm.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: helm-provider
spec:
  credentials:
    source: InjectedIdentity
---
apiVersion: helm.crossplane.io/v1beta1
kind: Release
metadata:
  name: cert-manager
  namespace: cert-manager
spec:
  forProvider:
    chart:
      name: cert-manager
      repository: https://charts.jetstack.io
      version: v1.5.0
    namespace: cert-manager
    set:
      - name: installCRDs
        value: "true"
  providerRef:
    name: helm-provider

What environment did it happen in?

Crossplane version:

$ helm upgrade --install crossplane crossplane --version 1.3.0 \
  --create-namespace \
  --namespace crossplane-system \
  --repo https://charts.crossplane.io/stable \
  --wait --timeout 300s

$ kubectl version 
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"c2b5237ccd9c0f1d600d3072634ca66cefdf272f", GitTreeState:"clean", BuildDate:"2021-08-04T17:56:19Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.8", GitCommit:"5575935422cc1cf5169dfc8847cb587aa47bac5a", GitTreeState:"clean", BuildDate:"2021-06-16T12:53:07Z", GoVersion:"go1.15.13", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.22) and server (1.20) exceeds the supported minor version skew of +/-1

support appVersion

What problem are you facing?

We are attempting to set a custom application version and found that appVersion is not supported.

How could Crossplane help solve your problem?

support passing appVersion to this provider.

patch template labels return cause error

What happened?

I was trying to update the lables of podtemplate of the wordpress example with the following patch

• patch: |-
  - op: add
  path: /spec/template/metadata/labels
  value:
  team-name: new-team
  app-name: newapp
  target:
  name: wordpress-example-patched
  kind: Deployment

Got an error "managed/release.helm.crossplane.io failed to upgrade release: failed to create resource: Deployment.apps "wordpress-example-patched" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app-name":"newapp", "team-name":"new-team"}: selector does not match template labels"

How can we reproduce it?

Add this code section to the release-with-patches.yml and do a kubectl --apply

What environment did it happen in?

Crossplane version: 1.5
AWS EKS with k8s version 1.19

Secret with "kubeconfig" key should work as provider config secret

Currently helm provider expects the keys here in the provider secret.

It should be possible to use a secret with "kubeconfig" key as provider config secret.

Release object in deployed state but not "Ready"

What happened?

Release object seems to be deployed OK to remote cluster, but it is not in the ready state.

> k get releases.helm.crossplane.io platform-ref-aws-cluster-8s97w-fsxdt
NAME                                   STATE      AGE
platform-ref-aws-cluster-8s97w-fsxdt   deployed   104m

Full release object output:

apiVersion: helm.crossplane.io/v1alpha1
kind: Release
metadata:
  annotations:
    crossplane.io/external-name: platform-ref-aws-cluster-8s97w-fsxdt
  creationTimestamp: "2020-10-21T13:25:17Z"
  finalizers:
  - finalizer.managedresource.crossplane.io
  generateName: platform-ref-aws-cluster-8s97w-
  generation: 2
  labels:
    crossplane.io/claim-name: platform-ref-aws-cluster
    crossplane.io/claim-namespace: default
    crossplane.io/composite: platform-ref-aws-cluster-8s97w
  name: platform-ref-aws-cluster-8s97w-fsxdt
  ownerReferences:
  - apiVersion: aws.platformref.crossplane.io/v1alpha1
    controller: true
    kind: Services
    name: platform-ref-aws-cluster-8s97w-jfwh2
    uid: 3277d3d1-5c4b-49b5-bbe2-d25a65a37629
  resourceVersion: "10740"
  selfLink: /apis/helm.crossplane.io/v1alpha1/releases/platform-ref-aws-cluster-8s97w-fsxdt
  uid: 7a327ddb-030a-4a8e-8d15-47c0ab1ffc05
spec:
  forProvider:
    chart:
      name: kube-prometheus-stack
      pullSecretRef:
        name: ""
        namespace: ""
      repository: https://prometheus-community.github.io/helm-charts
      version: 10.0.2
    namespace: operators
    values: {}
  providerConfigRef:
    name: platform-ref-aws-cluster
status:
  atProvider:
    releaseDescription: Install complete
    revision: 1
    state: deployed
  conditions:
  - lastTransitionTime: "2020-10-21T14:37:54Z"
    reason: ReconcileSuccess
    status: "True"
    type: Synced
  synced: true

How can we reproduce it?

This reproduced by deploying the AWS reference platform network and cluster objects, with fixes from upbound/platform-ref-aws#17.

What environment did it happen in?

Crossplane version: v0.14.0-rc.27.g225fdf28
provider-helm version: v0.3.3

prometheus charts repo is invalid?

What happened?

I created a release.helm.crossplane.io object that points at the https://prometheus-community.github.io/helm-charts helm chart repo, but I see an error message that it appears to be invalid:

    conditions:
    - lastTransitionTime: "2020-10-20T23:03:59Z"
      message: 'create failed: failed to install release: failed to pull chart: looks
        like "https://prometheus-community.github.io/helm-charts" is not a valid chart
        repository or cannot be reached: open /.cache/helm/repository/Lqeg3VO4wtqr3vbNRjfZ7j2irxk=-index.yaml:
        no such file or directory'

I expected this repo to be valid, because the instructions on https://prometheus-community.github.io/helm-charts/ say to do:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

What is invalid about? How can I fix this?

How can we reproduce it?

This is the full yaml for the release.helm.crossplane.io object I see this with:

apiVersion: helm.crossplane.io/v1alpha1
kind: Release
metadata:
  annotations:
    crossplane.io/external-name: platform-ref-aws-cluster-hmfxt-bt279
  creationTimestamp: "2020-10-20T22:29:24Z"
  finalizers:
  - finalizer.managedresource.crossplane.io
  generateName: platform-ref-aws-cluster-hmfxt-
  generation: 2
  labels:
    crossplane.io/claim-name: platform-ref-aws-cluster
    crossplane.io/claim-namespace: default
    crossplane.io/composite: platform-ref-aws-cluster-hmfxt
  name: platform-ref-aws-cluster-hmfxt-bt279
  ownerReferences:
  - apiVersion: aws.platformref.crossplane.io/v1alpha1
    controller: true
    kind: Services
    name: platform-ref-aws-cluster-hmfxt-sck7l
    uid: 38bb1440-d740-441b-9a92-bd1347967a89
  resourceVersion: "71863"
  selfLink: /apis/helm.crossplane.io/v1alpha1/releases/platform-ref-aws-cluster-hmfxt-bt279
  uid: a5bb45fa-9474-4371-9d7d-269311557033
spec:
  forProvider:
    chart:
      name: kube-prometheus-stack
      pullSecretRef:
        name: ""
        namespace: ""
      repository: https://prometheus-community.github.io/helm-charts
      version: 10.0.2
    namespace: operators
    values: {}
  providerConfigRef:
    name: platform-ref-aws-cluster
status:
  atProvider: {}
  conditions:
  - lastTransitionTime: "2020-10-20T23:08:01Z"
    message: 'create failed: failed to install release: failed to pull chart: looks
      like "https://prometheus-community.github.io/helm-charts" is not a valid chart
      repository or cannot be reached: open /.cache/helm/repository/X0AUrfHbH+Q4T8EoFX8JnEHnfBU=-index.yaml:
      no such file or directory'
    reason: ReconcileError
    status: "False"
    type: Synced

What environment did it happen in?

Crossplane version: v0.14.0-rc.27.g225fdf28
provider-helm version: v0.3.0