Improve Helm provisioner README doc and perhaps the provisioner

[cmoulliard]

Discussion

I tested the Helm provisionner using on a local fresh project cloned and started a kind cluster using make run. Next, I deployed the Helm BundleDeployment CRD as documented part of the README. The installation of the Helm chart worked as the following pod was created under the rukpak-system namespace

k get pods -n rukpak-system
NAME                                          READY   STATUS    RESTARTS   AGE
hello-world-helm-formvalues-5bd4cd455-vh7cp   1/1     Running   0          26m

Questions:

• Is a rukpak helm provisioner (e.g. helm-provisioner-7976ffb955-hthln) created under the rukpak-system for each BundleDeployment CRD ?

k get pods -n rukpak-system
NAME                                          READY   STATUS    RESTARTS   AGE
core-68fdd49c64-nns96                         2/2     Running   0          28m
helm-provisioner-7976ffb955-hthln             2/2     Running   0          28m
rukpak-webhooks-5b455665-6nfdc                1/1     Running   0          28m

• Where is the Helm's log as we only see the following messages part of the container helm-provisioner-7976ffb955-hthln/manager ?

1.660817157363545e+09    INFO    applying status changes    {"controller": "bundledeployment", "controllerGroup": "core.rukpak.io", "controllerKind": "BundleDeployment", "bun
dleDeployment": {"name":"hello-world-helm"}, "namespace": "", "name": "hello-world-helm", "reconcileID": "4ebc0edb-ddaa-458e-b91d-f6278bd91699"}
1.6608171573731465e+09    DEBUG    ending reconciliation    {"controller": "bundledeployment", "controllerGroup": "core.rukpak.io", "controllerKind": "BundleDeployment", "bun
dleDeployment": {"name":"hello-world-helm"}, "namespace": "", "name": "hello-world-helm", "reconcileID": "4ebc0edb-ddaa-458e-b91d-f6278bd91699"}
1.660817157373222e+09    DEBUG    starting reconciliation    {"controller": "bundledeployment", "controllerGroup": "core.rukpak.io", "controllerKind": "BundleDeployment", "bu
ndleDeployment": {"name":"hello-world-helm"}, "namespace": "", "name": "hello-world-helm", "reconcileID": "9dcf90ae-b4f8-4334-95b6-7350696a874c"}
1.6608171573779972e+09    DEBUG    preparing upgrade for hello-world-helm
1.6608171578183286e+09    DEBUG    performing update for hello-world-helm
1.660817157820441e+09    DEBUG    dry run for hello-world-helm
1.6608171578317251e+09    DEBUG    ending reconciliation    {"controller": "bundledeployment", "controllerGroup": "core.rukpak.io", "controllerKind": "BundleDeployment", "bun
dleDeployment": {"name":"hello-world-helm"}, "namespace": "", "name": "hello-world-helm", "reconcileID": "9dcf90ae-b4f8-4334-95b6-7350696a874c"}

[akihikokuroda]

Is a rukpak helm provisioner (e.g. helm-provisioner-7976ffb955-hthln) created under the rukpak-system for each BundleDeployment CRD

No, one provisioner pod handles all CRs.

Where is the Helm's log as we only see the following messages part of the container helm-provisioner-7976ffb955-hthln/manager

When an error happnes during helm install, the error from the helm api is logged in the provisioner pod log.

[cmoulliard]

No, one provisioner pod handles all CRs.

How can we tell to rukpak that we would like to install the provisioners A,B,D by example ?

[cmoulliard]

When an error happnes during helm install, the error from the helm api is logged in the provisioner pod log.

Nothing is currently logged. If I deploy manually the helm chart hello-word, then we should see the following message

helm install hello-world https://github.com/helm/examples/releases/download/hello-world-0.1.0/hello-world-0.1.0.tgz
NAME: hello-world
LAST DEPLOYED: Thu Aug 18 15:09:06 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=hello-world,app.kubernetes.io/instance=hello-world" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT

[akihikokuroda]

How can we tell to rukpak that we would like to install the provisioners A,B,D by example ?

That is not designed yet, I believe. ^ @operator-framework/rukpak-maintainers

Nothing is currently logged

Right. it logs only on install error.

[cmoulliard]

Right. it logs only on install error.

This is because the code used behind the rukpak helm provisioner only reports error - see here ?

[akihikokuroda]

Yes, the helm provisioner is using the function.

[cmoulliard]

It will be needed to improve that as users should be informed from the log about:

• Helm tool version used to install/uninstall the chart
• Log message (as we got using the helm client)
• Error message (if they are)
• Log of the NOTE.txt file execution

[awgreene]

This issue was discussed at the OLM Issue Triage Meeting, some notes:

• It seems reasonable to print the HELM version, log, and NOTE.txt to the bundleDeployment.Status.Conditions array. We believe that the reason for a failed helm install should be communicated to the user that created the CR.
• There was some concern around including the helm logs in the bundleDeployment.Status.Conditions array as we could hit ETCD size limits, but @joelanford pointed out that the helm-operator supported by the SDK does this today without any issue.

[timflannagan]

It looks like Alex had put this in the backlog, but if there's any immediate documentation gaps, then I think we'd want to queue those up for next minor version release.

[github-actions[bot]]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.

[akihikokuroda]

The NOTES.txt contexts are added into the condition of the BundleDeployment. The other information is other than the Error/Log messages are in the BundleDeployment already. The messages are in the provisioner pod log.

[github-actions[bot]]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.