Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-830

Phalanx Helm charts reorganization

    XMLWordPrintable

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      The Phalanx documentation describes the process for adding a new service to the Rubin Science Platform (RSP).

      In summary, it requires creating a Helm chart in the charts repository with the default configuration for the service and an Argo CD application in the phalanx repository with a small wrapper chart to hold the deployment configuration for each RSP environment.

      In this RFC, we propose creating the RSP Helm charts directly in the phalanx repository and eliminating the charts repository to simplify the development workflow.

       

      Why did we start with two repositories?

      The charts repository predates the phalanx repository, which was created to store the RSP deployment configuration managed by Argo CD and scripts to bootstrap an RSP installation.

      Argo CD supports several tools in which the Kubernetes manifests for an RSP service can be defined, including Helm, Kustomize, and others. See also SQR-035: Deployment engineering for Kubernetes-based services.

      Initially, because of the flexibility offered by Argo CD, we decided to keep the charts repository and use it to develop the RSP Helm charts. However, all RSP services use Helm today, and Kustomize services with multi-environment configuration are not currently supported.

       

      What is the current developer workflow?

      Every time we want to add a service developed by ourselves, for example, squareone, we create a new Helm chart in the charts repository. Then we add the Argo CD application and the wrapper chart with the multi-environment configuration to the phalanx repository.

      A GitHub Action in the charts repository automatically publishes the Helm chart each time a new version is merged to master, but we still need an additional commit in the phalanx repository to reference the new version.

      We have a similar workflow to add third-party Helm charts that require additional Kubernetes resources not part of the upstream chart (for example, a VaultSecret resource).

       

      Other considerations

      All Helm charts in the charts repository are related to the RSP. Sometimes, they are not deployed as part of the RSP like neophile, for example, but they are still essential to the RSP infrastructure.

      Working with two repositories may cause ambiguity. For example, we might add extra Kubernetes resources to the chart in the charts repository or directly to the wrapper chart in the phalanx repository.

      An advantage of publishing a Helm chart is that it can be shared with multiple RSP services. However, today's only example of a shared chart is the strimzi-registry-operator.

      We use helm-docs to generate documentation for the RSP Helm charts. Currently, this documentation lives in the charts repository, because of the chart default configuration (values.yaml). 

       

      What changes with the new organization?

      • We propose developing Helm charts for RSP services directly in the phalanx repository. They essentially become the wrapper charts under the services/ folder. These charts are not published anymore. 
      • We propose creating a new charts/ folder in the phalanx repository to develop and publish charts that are not deployed as part of the RSP or charts that are shared among RSP services.
      • With that, we can run helm-docs in the phalanx repository.

      Note that because we are not publishing these charts anymore, the version and other chart metadata become irrelevant. 

       

      Proof of concept

      We have used sasquatch as proof of concept and noticed the following additional advantages with the new organization:

      Conclusion

      The initial reason for having the charts repository doesn't exist anymore, and this reorganization simplifies the development workflow by keeping the RSP Helm charts in the phalanx repository along with the RSP deployment configuration. 

        Attachments

          Issue Links

            Activity

            Hide
            frossie Frossie Economou added a comment - - edited

            Alright it seems we have resolved the remaining questions. 

            In any case, the gory details:

            1. Charts clearly for a specific phalanx service will go in phalanx/services/[service]/ 
            2. Charts that may be shared among phalanx services will be located in {{phalanx/charts/[reusable-service]/}} and symlinked from phalanx/services/[service]/charts/[reusable-service] This maintains the pattern above but avoids code duplication. We have tested this does not have unintended consequences. 
            3. The same pattern will be followed for roundtable / future clusters services.
            4. Standalone charts that we treat as third parties (eg because we use them in both roundtable and phalanx, or make public for external users as standalone apps) will still go in the lsst-sqre/charts repo in order to avoid confusing open source users. Currently this would only be one or two services. 

            These are implementation details and do not affect the benefits of the RFC, which is to push service charts down to the phalanx repos in order to facilitate deployment workflow, allow testing services from a branch, and improving chart documentation. I am therefore adopting this RFC. 

             

            Show
            frossie Frossie Economou added a comment - - edited Alright it seems we have resolved the remaining questions.  In any case, the gory details: Charts clearly for a specific phalanx service will go in  phalanx/services/ [service] /   Charts that may be shared among phalanx services will be located in  {{ phalanx/charts/ [reusable-service] / }}  and symlinked from  phalanx/services/ [service] /charts/ [reusable-service]   This maintains the pattern above but avoids code duplication. We have tested this does not have unintended consequences.  The same pattern will be followed for roundtable / future clusters services. Standalone charts that we treat as third parties (eg because we use them in both roundtable and phalanx, or make public for external users as standalone apps) will still go in the  lsst-sqre/charts  repo in order to avoid confusing open source users. Currently this would only be one or two services.  These are implementation details and do not affect the benefits of the RFC, which is to push service charts down to the phalanx repos in order to facilitate deployment workflow, allow testing services from a branch, and improving chart documentation. I am therefore adopting this RFC.   
            Hide
            tjenness Tim Jenness added a comment -

            Can someone please update this RFC with a "is triggering" jira ticket?

            Show
            tjenness Tim Jenness added a comment - Can someone please update this RFC with a "is triggering" jira ticket?
            Hide
            tjenness Tim Jenness added a comment -

            Has this RFC been implemented? The triggered tickets have all been marked done.

            Show
            tjenness Tim Jenness added a comment - Has this RFC been implemented? The triggered tickets have all been marked done.
            Hide
            rra Russ Allbery added a comment -

            I've added the other triggered story that does the rest of the cleanup.

            Show
            rra Russ Allbery added a comment - I've added the other triggered story that does the rest of the cleanup.
            Hide
            tjenness Tim Jenness added a comment -

            Russ Allbery I think this RFC can now be marked as implemented.

            Show
            tjenness Tim Jenness added a comment - Russ Allbery I think this RFC can now be marked as implemented.

              People

              Assignee:
              afausti Angelo Fausti
              Reporter:
              afausti Angelo Fausti
              Watchers:
              Adam Thornton, Angelo Fausti, Christine Banek, Colin Slater, Frossie Economou, Jonathan Sick, Joshua Hoblitt, Russ Allbery, Russell Owen, Tim Jenness
              Votes:
              1 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Planned End:

                  Jenkins

                  No builds found.