Owner: Architect:

David Peraza

Story (Required)

As a Helm backend developer I will like to know if ODC frontend can track helm releases asynchronously so that we avoid having to wait for long running chart with a lot of sub-charts.

Background (Required)

Helm ODC frontend makes call to the helm backend and waits for the install call to finish. In most cases this is OK, however as chart are becoming more complex and contain more dependencies, it is becoming possible that the install call will not be done before browser times out of GET request. To solve this problem we can treat helm install as asynchronous operation. We will like to investigate if the state of the release can be tracked using the secret that represents the release.

Glossary

NA

Out of scope

Implementing the backend and frontend changes

In Scope

Document the Design and validate with ODC team.

Approach(Required)

Some initial investigation shows to be promising. Helm releases do keep a state as described here: https://helm.sh/docs/helm/helm_status/

As an example here is the gitlab chart status while it was installing:

"kind": "Secret",
"metadata": {
"creationTimestamp": "2022-10-17T15:30:35Z",
"labels":

{ "modifiedAt": "1666020638", "name": "gitlab", "owner": "helm", "status": "pending-install", "version": "1" }

,
"name": "sh.helm.release.v1.gitlab.v1",
"namespace": "default",
"resourceVersion": "503220",
"uid": "05723721-24a1-4f88-a01a-f58f4dfb24e7"
},
"type": "helm.sh/release.v1"
}

The ODC backend can potentially return right away to frontend while it continues to wait for the install call to return.

The frontend can then switch to a view of the release where the ui can pull the status of the release in the secret. The secret will follow this patter to be able to identified sh.helm.release.v1.[name_of_release].[version_of_release]. We can also search for secrets with labels (owners: helm) and (name: [name_of_release]).

Backend could also retry in cases where the helm chart gets specific errors we know are rise condition like this one: https://bugzilla.redhat.com/show_bug.cgi?id=1934604. During retry the user might see the release change from failed to installing to pending-install.

Things to investigate:
#Are above scenarios possible?
#What are the UI changes we will need to make?
#How would this affect the user experience today?
#How do we handle the transition while retrying from failed to pending-install?
#What is the backend mechanism to continue to run things on the backend while returning right away to the UI. (Multi-threading, multi-process, Jobs)?

Demo requirements(Required)

No Demo

Dependencies

NA

Edge Case

NA

Acceptance Criteria

We Have a document with design artifacts, including code changes required and user experience flows.
We have mock up screens we can review with ODC team.

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

v

Legend

Unknown

Verified

Unsatisfied