Skip to content

Reconfigure Linseed and linseed user when migrating from multi-index to single-index - #5132

Open
asincu wants to merge 4 commits into
masterfrom
index_migration_backport
Open

Reconfigure Linseed and linseed user when migrating from multi-index to single-index#5132
asincu wants to merge 4 commits into
masterfrom
index_migration_backport

Conversation

@asincu

@asincu asincu commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Description

  • Linseed will reconfigure its environment variables to set the correct backend for the
    indices it is using and also set the base index name used for Cloud.
  • ES Kubecontrollers will stop running elasticsearch configuration
  • LogStorage Controllers Users will configure Linseed user instead of es-kubecontrollers.

Release Note

TBD

For PR author

  • Tests for change.
  • If changing pkg/apis/, run make gen-files
  • If changing versions, run make gen-versions

For PR reviewers

A note for code reviewers - all pull requests must have the following:

  • Milestone set according to targeted release.
  • Appropriate labels:
    • kind/bug if this is a bugfix.
    • kind/enhancement if this is a a new feature.
    • enterprise if this PR applies to Calico Enterprise only.

asincu added 3 commits July 31, 2026 15:23
cluster

This will be set operator bootstrap config map and enabled when
migrating from multi-index format to single-index format. Linseed will
reconfigure its environment variables to set the correct backend for the
indices it is using and also set the base index name used for Cloud.
…hile migrating to single-index storage

Single-tenant clusters migrating to single-index storage need Linseed to hold
RBAC for the new calico_* indices. es-kube-controllers cannot grant that, so
during the migration the operator's log-storage users controller takes over
user provisioning and es-kube-controllers stops running its elasticsearch
configuration controller.

- Run the users controller in single-tenant mode when IndexMigration is set,
  building the tenant configuration from the cloud config ConfigMap since
  single-tenant clusters have no Tenant resource.
- Name the single-tenant Linseed and Dashboards users the way
  es-kube-controllers named them (<name>-<tenantID>-secure), and repoint
  existing credential secrets at those users while keeping their passwords, so
  credentials provisioned before the migration keep resolving.
- Declare the standard single-index names on the Tenant that CloudConfig.ToTenant
  builds, gated on the caller opting in, so that clusters which are not migrating
  keep falling back to their existing index names. Sort the declared indices, as
  they are generated from a map.
- Report the users TigeraStatus in the log-storage conditions aggregate while
  migrating.
…rom writing on every reconcile

updateConditions built its result by ranging over the desiredConditions map,
so the order of LogStorage.Status.Conditions was randomized on every
reconcile. Conditions is an atomic list, so a reorder is a real change to the
stored object: each reconcile bumped the resourceVersion, and since this
controller also watches LogStorage, that re-enqueued itself. The write loop
ran continuously, and reconciles fired faster than the informer cache could
converge - so reconciles read a stale tigera-secure and their status updates
were rejected with "the object has been modified".

Sort the conditions by type so the stored list is stable, skip the status
update entirely when the computed conditions match what is already stored, and
requeue instead of erroring when an update does hit a conflict.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants