Search docs.molo17.com

    Update status and history

    The Gluesync Kubernetes Operator (GKO) keeps everything about updates in the status of the GluesyncPlatform and in Kubernetes events. You can read it with kubectl, whether the update started from the UI or from Git.

    Overview

    kubectl -n gluesync-dev get gsp
    NAME       PHASE      VERSION   DESIRED   AVAILABLE   AGE
gluesync   Updating   2.3.2.1   2.3.2.2   2.3.2.2     6d
    Column Meaning

    PHASE

    See Phases.

    VERSION

    Core Hub version that runs.

    DESIRED

    spec.version, the Core Hub version asked for.

    AVAILABLE

    Latest Core Hub version on the release channel. Empty for an offline install.

    Add -w to follow an update as it runs.

    Phases

    Phase Meaning

    Current

    Core Hub runs the latest version on the channel, or no newer version is known.

    UpdateAvailable

    A newer Core Hub version is available on the channel.

    Updating

    An update is running.

    Degraded

    The last update finished, but a module was rolled back or some pipelines were not resumed.

    Failed

    The last update failed and Core Hub was rolled back.

    Degraded and Failed stay until the spec changes, for example with the next update request. A Refused update does not change the phase; its reason is in status.lastAttempt and in the events.

    Follow the running update

    The step being run and the latest message:

    kubectl -n gluesync-dev get gsp gluesync \
  -o jsonpath='{.status.update.step}{"\t"}{.status.message}{"\n"}'

    The steps are Preflight, Snapshot, Drain, CoreHub, CoreHubRollback, Resume, Modules and Finish, see Steps.

    The pipelines the update has put into maintenance mode and not yet resumed:

    kubectl -n gluesync-dev get gsp gluesync -o jsonpath='{.status.pausedPipelines}{"\n"}'

    Events

    GKO records an event on the GluesyncPlatform at each step:

    kubectl -n gluesync-dev describe gsp gluesync
kubectl -n gluesync-dev get events --field-selector involvedObject.kind=GluesyncPlatform
    Reason When

    UpdateStarted

    An update starts.

    PipelinesPaused

    The running pipelines were asked to enter maintenance mode.

    DrainTimeout

    The pipelines did not reach maintenance mode in time; the update is refused.

    CoreHubPatched

    The Core Hub image was changed.

    CoreHubUpdated

    Core Hub passed its stability check.

    CoreHubFailed

    Core Hub failed its stability check and is being rolled back.

    PipelinesResumed

    The paused pipelines were taken out of maintenance mode.

    ModuleRolledBack

    A module failed its stability check and is back on its previous version.

    UpdateSucceeded, UpdateDegraded, UpdateFailed, UpdateRefused

    The update ended with this result.

    OperatorUpdateScheduled

    GKO will update itself after this update.

    OperatorRestarting

    GKO changed its own image; the new pod is starting.

    OperatorUpdated

    The new GKO passed its stability check.

    OperatorRollingBack, OperatorRolledBack

    The new GKO did not come up; the old one put its own image back.

    OperatorUpdateFailed

    GKO did not come back on its previous version after a rollback.

    OperatorUpdateCancelled

    GKO’s own update was dropped: its image was changed by someone else meanwhile, or the self-update was turned off.

    Kubernetes keeps events for a limited time, one hour by default. The status keeps the outcome for longer.

    Last attempt

    kubectl -n gluesync-dev get gsp gluesync -o yaml

    Under status, lastAttempt looks like this:

    target: 2.3.2.2
result: Succeeded
message: update finished
finishedAt: "2026-11-13T09:12:41Z"
results:
  - name: gluesync-gluesync-core-hub
    status: OK
    from: 2.3.2.1
    to: 2.3.2.2
  - name: gluesync-gluesync-chronos
    status: OK
    from: 0.3.2
    to: 0.3.3
pausedPipelines: ["<pipeline id>"]
resumedPipelines: ["<pipeline id>"]

    results has one entry per component, with its status (OK, ERROR, ROLLED_BACK or SKIPPED) and, on a failure, its message. GKO’s own entry is SCHEDULED until GKO has restarted on its new version, then OK, ROLLED_BACK or ERROR. While GKO updates itself, its Deployment carries the annotation gluesync.molo17.com/self-update with the phase (Scheduled, RollingOut or RollingBack):

    kubectl -n gluesync-dev get deploy -l com.molo17.conductor.type=operator \
  -o jsonpath='{.items[0].metadata.annotations.gluesync\.molo17\.com/self-update}'

    History

    status.history keeps the last 10 updates, newest first:

    kubectl -n gluesync-dev get gsp gluesync \
  -o jsonpath='{range .status.history[*]}{.finishedAt}{"\t"}{.from}{" -> "}{.to}{"\t"}{.result}{"\t"}{.message}{"\n"}{end}'

    Each entry has:

    Field Description

    from, to

    Core Hub version before and after. to is empty for an update of modules only.

    result

    Succeeded, Degraded, Failed or Refused.

    message

    Outcome, with the reason of a failure.

    finishedAt

    When the update ended.

    previousImages

    The image of each component before the update. Use them to go back to an earlier version by hand.

    Components

    The workloads GKO manages, their image, the latest available version and whether they are Ready:

    kubectl -n gluesync-dev get gsp gluesync \
  -o jsonpath='{range .status.components[*]}{.name}{"\t"}{.version}{"\t"}{.available}{"\t"}{.ready}{"\n"}{end}'

    Check for updates now

    GKO checks the version catalog every spec.checkIntervalMinutes (360 minutes by default). To check at once, set the annotation gluesync.molo17.com/check-now to a new value:

    kubectl -n gluesync-dev annotate gsp gluesync --overwrite gluesync.molo17.com/check-now="$(date +%s)"