Skip to content

Migration uses full Update (c.Apply) on operator-owned CHI off a possibly-stale read #8

Description

@jtomaszon

migrateCHIToReplicated() + c.Apply() performs a full client.Update on the ClickHouseInstallation, which the Altinity operator owns and continuously mutates. The CHI is read via a non-watched c.Get() (potentially stale, since the provider intentionally does not watch CHI/CHK).

Risk: clobbering operator-normalized fields, or update conflicts under operator churn. The "only fields we own" comment is aspirational — a full Update does not enforce it.

Suggested fix: switch the migration mutation to a field-owned Server-Side Apply (or strategic-merge patch) that touches only spec.configuration.zookeeper and clusters[0].layout.replicasCount.

Held fine in the live k3d e2e (Altinity 0.27.1) but not robust by construction. Ref: PR #6.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions