Uploaded image for project: 'Helm'
  1. Helm
  2. HELM-433

Investigate how to track helm releases asynchronously from ODC

    XMLWordPrintable

Details

    • Story
    • Resolution: Done
    • Undefined
    • None
    • None
    • Helm
    • None
    • 5
    • AppSvc Sprint 227

    Description

      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

      Attachments

        Issue Links

          Activity

            People

              kmamgain@redhat.com Kartikey Mamgain
              dperaza@redhat.com David Peraza
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: