Skip to content

[PRODENG-3744] Use KDD datastore by default - #72

Merged
nekwar merged 1 commit into
mainfrom
PRODENG-3744
Sep 16, 2026
Merged

nekwar merged 1 commit into
mainfrom
PRODENG-3744

Conversation

@nekwar

@nekwar nekwar commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

Gate --calico-datastore-type-kdd behind calico_datastore_type_kdd (default true) instead of hardcoding it in mke_install_flags.

Known MKE3 issue: with KDD enabled, MKE brings up the calico-kube-controllers Deployment (kube-system) wired to the calico-node ServiceAccount instead of its own calico-kube-controllers ServiceAccount, so it cannot sync from the Kubernetes API.

tasks/calico-kdd-patch-tasks.yml patches the Deployment's serviceAccountName via mke-post-install-playbook.yml. That play runs the patch last, after cluster-upgrade-controller/machine-config-controller/ SUC install: installing those was observed to trigger MKE to re-sync its baseline kube-system manifests, reverting the patch if applied before them. Verified against a live cluster end-to-end, including that the fix holds once nothing else in the run mutates the cluster afterward.

@nekwar nekwar changed the title [PRODENG-3744] Patch calico-kube-controllers ServiceAccount for KDD datastore [PRODENG-3744] Use KDD datastore by default Sep 14, 2026
@nekwar

nekwar commented Sep 16, 2026

Copy link
Copy Markdown
Contributor Author

after discussion with the team, we decided to not use KDD by default for now, however it could be needed in the future. So keep the code, but set variable to false by default

tasks:
- name: Patch calico-kube-controllers service account
ansible.builtin.include_tasks: tasks/calico-kdd-patch-tasks.yml
when: calico_datastore_type_kdd | bool

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Medium - KDD repair task is skipped for clusters that enable the datastore through existing install-flag overrides

The new service-account patch runs only when calico_datastore_type_kdd is true, but the code still exposes the generic mke_install_flags override and documents mke-post-install-playbook.yml as a standalone flow. That means a cluster can be installed with --calico-datastore-type-kdd through the existing flag list while this new boolean stays at its default false, causing post-install to skip the fix entirely. In that state calico-kube-controllers keeps running as calico-node and hits the RBAC-forbidden/CrashLoop behavior this PR is meant to prevent, so the repair is unreliable for valid KDD deployments.

Show fix

Drive the patch from the effective install configuration or live cluster state instead of a second manually-synchronized boolean, or at least fail fast when KDD is present in mke_install_flags but calico_datastore_type_kdd is false.

More info - Reply on this comment to give feedback or ignore the issue.

Gate --calico-datastore-type-kdd behind calico_datastore_type_kdd
(default true) instead of hardcoding it in mke_install_flags.

Known MKE3 issue: with KDD enabled, MKE brings up the
calico-kube-controllers Deployment (kube-system) wired to the
calico-node ServiceAccount instead of its own calico-kube-controllers
ServiceAccount, so it cannot sync from the Kubernetes API.

tasks/calico-kdd-patch-tasks.yml patches the Deployment's
serviceAccountName via mke-post-install-playbook.yml. That play runs
the patch last, after cluster-upgrade-controller/machine-config-controller/
SUC install: installing those was observed to trigger MKE to re-sync
its baseline kube-system manifests, reverting the patch if applied
before them. Verified against a live cluster end-to-end, including
that the fix holds once nothing else in the run mutates the cluster
afterward.
@nekwar
nekwar merged commit a287e62 into main Sep 16, 2026
3 checks passed
@james-nesbitt
james-nesbitt deleted the PRODENG-3744 branch September 16, 2026 13:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants