YokeCD: hard refresh required to pick up changes to OCI flight

[ssmall]

Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: hello-world
  namespace: argocd
spec:
  destination:
    name: in-cluster
    namespace: default
  project: default
  source:
    path: ./cmd/pg
    plugin:
      name: yokecd
      parameters:
      - name: wasm
        string: oci://us-west2-docker.pkg.dev/REDACTED/hello_world:latest
    repoURL: https://github.com/davidmdm/yokecd-demo
    targetRevision: main
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

when I push a new version of my flight using yoke stow, the changes are not picked up in ArgoCD until I do a hard refresh of the application. Is this the intended behavior?

[davidmdm]

The problem here is that your oci url is using tag latest.

To some degree this is not a yokecd problem but an ArgoCD problem. How is argocd to be notified when the source for a specific tag changes?

Without refreshing and reevaluating (pulling, compiling and executing the wasm module) it can't know that there's anything to do.

Yokecd (the plugin) only gets invoked when ArgoCD decides it's time to sync/refresh the application.

The indirect process based solution would be to update the oci module with a new tag, and to update the application to use the new tag.

So I believe this issue is outside the scope of the plugin.

However I am open to ideas if there's a way yoke can improve the situation!

In flux land there are source controllers that poll for these kind of OCI repository changes but I don't know that there's anything similar in Argo. But if there is that would be our best bet. We would just need to connect the oci repo / application to that event stream. (If that exists)

[ssmall]

Agreed that using the latest tag is ultimately not a yokecd problem.

The Helm plugin provides some ability to track version ranges. I'm hoping to move away from Helm toward YokeCD, however version tracking is a feature that I currently rely on. Right now my only alternative with YokeCD is to enable periodic hard-refresh of all applications and rely on a mutable OCI tag, which has a number of drawbacks.

[davidmdm]

@ssmall can you explain in more detail exactly what your current workflow is? Then we can look into if we can make the same workflow possible with a CMP.

[ssmall]

My current workflow is:

1. ArgoCD applications track Helm chart version like so:

source:
  chart: my-chart
  repoURL: us-west2-docker.pkg.dev/REDACTED/helm
  targetRevision: ">=0.0.1-0"

2. CI generates new Helm chart artifacts on release, tags them with a new semantic version
3. ArgoCD picks up new chart versions and syncs during sync window

I am exploring replacing Helm with Yoke, using YokeCD to replicate the functionality that the ArgoCD Helm plugin currently provides.

[seanturner026]

In flux land there are source controllers that poll for these kind of OCI repository changes but I don't know that there's anything similar in Argo. But if there is that would be our best bet. We would just need to connect the oci repo / application to that event stream. (If that exists)

Makes me think of ArgoCD Image Updater with an argocd update method (rather than git this doesn't create a commit). This polls a Container Registry every 2 mins or so for Image definition(s) which are Image Updater annotations on the ArgoCD Application.

https://argocd-image-updater.readthedocs.io/en/stable/basics/update-methods/#overview
https://argocd-image-updater.readthedocs.io/en/stable/configuration/images/

Granted this is a service that runs in the k8s Cluster, but, it's doing the same thing. A digest update strategy would cause Image Updater to look at the Registry, get the digest (e.g. sha) of latest in the registry and trigger an update to the Application resources if there's a difference between what's in the registry and what's defined in the Cluster.

https://argocd-image-updater.readthedocs.io/en/stable/basics/update-strategies/#update-strategies
https://argocd-image-updater.readthedocs.io/en/stable/examples/#digest

[davidmdm]

@seanturner026 thats really interesting! However how might this work within the context of a CMP?

I am thinking the CMP would have to embed the updater (hopefully some of its functionality is public via a Go SDK) and the plugin would need to use it to manage its cache? And call ArgoCD update on relevant applications?

[seanturner026]

At this time, no idea! I think it depends on how the CMP (I've never used these before) interacts with the Application manifest.

Image Updater works by tracking updates on the Application manifest itself (this is towards the bottom).

  sync:
    comparedTo:
      destination:
        namespace: service-web
        server: https://kubernetes.default.svc
      source:
        kustomize:
          images:
          - account.dkr.ecr.region.amazonaws.com/repo@sha256:some-uuid-alkksdfkliwoejiomjalksdmflaksdmflskdamflkasdmf
        path: apps/service-web/overlays/cluster-name
        repoURL: https://github.com/org/repo-name
        targetRevision: main

This is showing that the e.g. latest image (what we define in our Kustomization.yaml) was replaced by a new image with a UUID by the ArgoCD Image Updater.

That all tells ArgoCD yes, latest isn't deployed anymore because we don't want it to be deployed anymore. Instead we want the sha256 digest image that you're aware of to be deployed. So all is well.

I had a play around with yokecd last weekend, didn't get too sophisticated however (e.g. no ArgoCD). I'll chime in if I end up having a go at that and share what I find.