Expand Helm DeploymentProfile to Support Both OCI Repository and Git/Code Repository

[jjaswanson4]

Description

Currently, the Helm DeploymentProfile requires use of charts stored in an OCI registry, which are packaged up as archives.

It's also common to see charts stored in Git repos, which can be pulled using standard git mechanisms (ssh, http), then applied using the same helm tooling as what's used for charts in OCI registries.

Motivation

Storing helm charts in a git repo is a valid and often used process, allowing for rapid testing and prototyping, as well as facilitating collaborations during the development of an application and supporting chart.

Proposed Solution (optional)

Expand .ApplicationDescription.deploymentProfiles, for type helm.v3, to allow for the properties.repository field to allow for both OCI and git endpoints.

The current spec shows:

deploymentProfiles:
  - type: helm.v3
    components:
      - name: database-services
        properties: 
          repository: oci://quay.io/charts/realtime-database-services
          revision: 2.3.7
          wait: true
          timeout: 8m30s

This could be expanded to allow for:

deploymentProfiles:
  - type: helm.v3
    components:
      - name: grafana-dashboard
        properties: 
          # Could be http(s) or ssh, depending on the repository
          repository: https://github.com/grafana/helm-charts
          # Path within the repository
          path: charts/grafana/
          # Revision now points to branch, tag, etc, as denoted in the repository
          revision: main
          wait: true
          timeout: 8m30s

This aligns to other tooling that "consumes" helm charts for deployments to k8s-compliant endpoints. This is an example section of an Application that ArgoCD would deploy:

  source:
    path: argocd-example-apps
    repoURL: https://github.com/stevesea/argocd-helm-app-of-apps-example.git
    targetRevision: test
    helm:
      valueFiles:
      - test-values.yaml

Same concept, where charts can be pulled from an OCI-compliant endpoint, or from a code repository.

[phil-abb]

@jjaswanson4 This would mean all devices must support both OCI and Git (unless we change our current approach). The community has already indicated we do not want devices to depend on Git. There are several reasons why this is the case. Several of them are mentioned in this issue.

[jjaswanson4]

1. If we're not going to provide "like-for-like" functionality with existing tools, when what value does Margo provide here? Existing tools are more feature-rich, thus making them the preferred option for this element of the deployment flow.

2. Devices must already be OCI compliant, meaning they must be able to:

• make web calls to download
• have a scratch space to extract the downloaded content
• have appropriate tooling to extract the downloaded content into the scratch space
• have the appropriate tooling to act on the extracted content

The docker-compose deploymentProfile follows mostly the same flow as well:

  - type: docker-compose
    components:
      - name: digitron-orchestrator-docker
        properties:
          packageLocation: https://northsitarida.com/digitron/docker/digitron-orchestrator.tar.gz
          keyLocation: https://northsitarida.com/digitron/docker/public-key.asc

Git, under the covers, basically follows the same flow. Only difference is the packaging format here - .tar.gz vs. .git.

In addition, Git is already a requirement in the workload deployment section of the spec: https://specification.margo.org/fleet-management/workload/workload-deployment/

3. This is why asking the devices/agents on the devices to do all of the heavy lifting, such as downloading, rendering, applying, etc, is probably not the best approach. If the workload manager/orchestrator were to inherit this responsibility, then any concern around "the agent/device needing to do more work" is eliminated.

4. Git is a universally accepted standard. Adherence to the standard is determined by interoperability with the git codebase: https://web.git.kernel.org/pub/scm/git/git.git

5. Specifically to some of the concerns in Replace using Git as the transport mechanism for desired state #76, this is not a mechanism for "reconciliation" or enforcement, it is simply a way to deliver flat files/content to a device. The best practice for storing flat files (or even archived files, etc), is to store them in source control, period. If Margo doesn't plan to support a universal standard, then there's significant risk to adoption.

[phil-abb]

Git, under the covers, basically follows the same flow. Only difference is the packaging format here - .tar.gz vs. .git.

If it's just a matter of downloading a single file that is hosted in a git repository that's one thing but if we're saying the device has to clone the repo that is where we get into the area where community members had concerns about using Git in general, not just for managing the desired state.

In addition, Git is already a requirement in the workload deployment section of the spec: https://specification.margo.org/fleet-management/workload/workload-deployment/

The specification is out of date. The community has agreed we won't use Git (see this issue) but we haven't decided on the alternative yet (that's this issue) so the specification hasn't been updated. We should probably put a note on that page indicating we're no longer using Git for this.

3. This is why asking the devices/agents on the devices to do all of the heavy lifting, such as downloading, rendering, applying, etc, is probably not the best approach. If the workload manager/orchestrator were to inherit this responsibility, then any concern around "the agent/device needing to do more work" is eliminated.

Agreed, I think we need to revisit that conversation because it was mentioned and discussed a little bit but we never came to any conclusions on which direction we felt was best for Margo.