Support dynamic runtime configuration of resources managed by a BD

[exdx]

The BundleDeployment conceptually is similar to a Pod -- it is responsible for deploying and managing content external to the cluster. There is a strong desire, particularly in GitOps workflows, to be able to configure the runtime properties of this content in a declarative way. This is partially supported today in OLM via the subscription config which enables users to modify their operator deployment at subscription time.

This tracking ticket is meant to support the same type of functionality within rukpak. There would likely be a higher-level API that is responsible for subscription type behavior. This API should be able to pass information downwards to the BD such that it can configure the runtime properties of the content that its managing, so GitOps users can declaratively modify resources that are being deployed by RukPak.

[raballew]

I believe the core functionality of deploying and manging content external to the cluster is a niche that currently can only be filled using custom tooling and another kind of distribution mechanism. I have been experimenting with OCI artifact images (OCI distribution spec) in the past in conjunction with tooling such as ORAS and custom wrapper functionality to achieve a similar result. The reality is, that this just adds another layer ontop of an already working distribution mechanism. Repositories can be cloned, e.g. Hence wrapping regular artifacts into a container image, publishing them in a different format just to consume them in a uniform way and storing it in a volume or similar felt weird sometimes.

This even leaves out the fact that patches to the content sometimes needed to be applied at runtime. This could either be a patch for files of a git repository or a compressed archive depending on runtime information. When it comes to subscription configs patching for example is required if one would like to use multi-homed operator pods.

[timflannagan]

This may be related to the conversation in #460 too.

[akihikokuroda]

Helm provisioner takes the configuration(values.yaml contents) in the BD config section and applies it during helm install.

kind: BundleDeployment
metadata:
  name: my-ahoy
spec:
  provisionerClassName: core.rukpak.io/helm
  config:
    values: |
      # Default values for hello-world.
      # This is a YAML-formatted file.
      # Declare variables to be passed into your templates.
      replicaCount: 1
      image:
        repository: nginx
        pullPolicy: IfNotPresent
        # Overrides the image tag whose default is the chart appVersion.
        tag: ""
      nameOverride: "fromvalues"
      fullnameOverride: ""
      serviceAccount:
        # Specifies whether a service account should be created
        create: true
        # Annotations to add to the service account
        annotations: {}
        # The name of the service account to use.
        # If not set and create is true, a name is generated using the fullname template
        name: ""
      service:
        type: ClusterIP
        port: 80
  template:
    metadata:
      labels:
        app: my-ahoy
    spec:
      provisionerClassName: core.rukpak.io/helm
      source:
        http:
          url: https://github.com/helm/examples/releases/download/hello-world-0.1.0/hello-world-0.1.0.tgz  
        type: http

When the configuration in the BD is updated, the helm chart is reinstalled with the new config. https://github.com/operator-framework/rukpak/pull/473

[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.