Search docs.molo17.com

    Update from Git and Argo CD

    The Gluesync Kubernetes Operator (GKO) works with a Gluesync install kept in Git. Decide who owns the Core Hub version, the Core Hub UI or Git, and tell your GitOps tool to leave alone what GKO changes.

    Why GitOps needs extra settings

    GKO changes two things that Helm also renders:

    • the spec.version, spec.modules and spec.requestID of the GluesyncPlatform, when an update starts from the UI;

    • the container image of Core Hub and of the modules, when it updates them.

    When Helm runs against the cluster (helm upgrade), the kit and the GKO chart read these live values with the Helm lookup function and keep them, so an upgrade never undoes an update. Argo CD renders the charts without cluster access, so lookup finds nothing: every sync would put back the versions written in Git. For Core Hub, that would also bypass maintenance mode and the stability check. The settings below prevent it.

    Choose an update policy

    updatePolicy: ui updatePolicy: gitops

    Who starts updates

    Platform updates in the Core Hub UI. Git sets the versions of the first install only.

    A commit that changes the version in Git. The UI cannot start updates.

    Version in Git

    The first install’s version. The live version moves ahead of it.

    Always the version that runs, or the next one.

    Argo CD ignores

    GluesyncPlatform /spec/version, /spec/modules, /spec/requestID, and workload images

    GluesyncPlatform /spec/requestID, and workload images

    In both cases GKO, not Argo CD, changes the images, so every update gets maintenance mode, the stability check and rollback.

    Argo CD with updatePolicy: ui

    Operator chart

    Add to the Argo CD Application that installs the GKO chart, or the kit when the kit includes GKO:

    spec:
  ignoreDifferences:
    # The Core Hub UI and GKO change these; Git sets the first install only.
    - group: gluesync.molo17.com
      kind: GluesyncPlatform
      name: gluesync
      jsonPointers:
        - /spec/version
        - /spec/modules
        - /spec/requestID
  syncPolicy:
    syncOptions:
      - RespectIgnoreDifferences=true    # a sync keeps the ignored fields
      - ServerSideApply=true             # the custom resource definition is large
      - SkipDryRunOnMissingResource=true # the GluesyncPlatform syncs with its definition

    Kit workloads

    Add to the Application that installs the kit:

    spec:
  ignoreDifferences:
    # GKO changes the images; Git sets the first install's tags.
    - group: apps
      kind: StatefulSet
      jqPathExpressions:
        - .spec.template.spec.containers[].image
    - group: apps
      kind: Deployment
      name: gluesync-gluesync-grafana
      jqPathExpressions:
        - .spec.template.spec.containers[].image
    - group: apps
      kind: Deployment
      name: gluesync-gluesync-prometheus
      jqPathExpressions:
        - .spec.template.spec.containers[].image
  syncPolicy:
    syncOptions:
      - RespectIgnoreDifferences=true

    Name each Deployment GKO manages, so that the images of other Deployments still follow Git. When the kit and GKO are in the same Application, put both lists in it.

    From GKO 0.2.0, GKO also updates its own Deployment. Either let it, and add its Deployment to the list:

        - group: apps
      kind: Deployment
      name: gluesync-gluesync-operator   # kit; GKO's chart: gluesync-operator
      jqPathExpressions:
        - .spec.template.spec.containers[].image
        - .metadata.annotations["gluesync.molo17.com/self-update"]

    or keep GKO’s version in Git: set operator.selfUpdate.enabled: false (kit) or selfUpdate.enabled: false (GKO’s chart), and change GKO’s tag in Git.

    Without RespectIgnoreDifferences=true, Argo CD only hides the difference: the next sync still writes the Git value.

    From GKO 0.3.0, a disaster-recovery setup made from the Core Hub UI changes the Core Hub and Chronos StatefulSets too: add the ignoreDifferences of Disaster recovery on Kubernetes.

    Argo CD with updatePolicy: gitops

    Set the policy:

    • kit: operator.updatePolicy: gitops;

    • operator chart: platform.updatePolicy: gitops.

    To update, commit the new Core Hub version:

    • kit: gluesyncCoreHub.tag, which the kit writes into spec.version;

    • operator chart: platform.version, and module pins in platform.modules.

    Argo CD changes spec.version of the GluesyncPlatform, and GKO runs the update. Keep the image ignoreDifferences of the kit workloads shown above: without them, Argo CD would change the Core Hub image itself, without maintenance mode or rollback. Ignore only /spec/requestID on the GluesyncPlatform, so that you can retry an update with kubectl, see Retry an update.

    A request from the Core Hub UI gets an answer that updates of this install are managed in Git, and GKO changes nothing. GKO does not update itself either: change its tag in Git (kit: operator.tag; GKO’s chart: image.tag).

    With the kit, unpinned modules move to the latest version on the release channel whenever Core Hub is updated. To pin module versions from Git, install GKO with its own chart and set platform.modules.

    After an update

    GKO never writes to Git. With updatePolicy: ui, the version in Git stays the one of the first install. To see what runs, read the GluesyncPlatform, see Update status and history.

    When you rebuild the install from Git, for example in a new cluster, it starts from the versions in Git. Update the versions in Git from time to time, so a rebuild starts close to what runs.