janhoy opened a new issue, #872:
URL: https://github.com/apache/solr-operator/issues/872
## Summary
The operator writes its computed defaults back into the SolrCloud spec with
a plain `Update`, which makes it the exclusive field manager for every field in
the object, including fields that were authored by whoever created the
SolrCloud. Helm 4 applies server-side by default, so from the second `helm
upgrade` onwards any chart that manages a SolrCloud fails with a field
ownership conflict. Helm 3 used client-side apply and never hit this.
## Reproduce
With Helm 4 (tested on v4.3.1), install a chart that templates a SolrCloud
setting anything under `spec.customSolrKubeOptions`, let the operator reconcile
it once, then upgrade the release:
```
Error: UPGRADE FAILED: conflict occurred while applying object my-ns/my-solr
solr.apache.org/v1beta1, Kind=SolrCloud: Apply failed with 1 conflict: conflict
with "solr-operator" using solr.apache.org/v1beta1:
.spec.customSolrKubeOptions.podOptions.initContainers
```
`managedFields` on the live object shows the two writers and the operations
they used:
```
manager='helm' op=Apply spec fields: additionalLibs,
availability, busyBoxImage, customSolrKubeOptions, dataStorage, replicas,
scaling, solrAddressability, solrImage, ...
manager='solr-operator' op=Update spec fields: customSolrKubeOptions,
solrAddressability, updateStrategy
```
Observed on operator v0.9.1 and v0.10.0-prerelease, Kubernetes 1.36.1.
## Cause
`controllers/solrcloud_controller.go:111`:
```go
changed := instance.WithDefaults(logger)
if changed {
logger.Info("Setting default settings for SolrCloud")
if err = r.Update(ctx, instance); err != nil {
return reconcile.Result{}, err
}
return reconcile.Result{Requeue: true}, nil
}
```
`WithDefaults` mutates the spec and the result is persisted with `Update`,
not `Apply`. A plain `Update` claims ownership of every field present in the
submitted object, not just the ones the operator actually defaulted, so the
operator ends up owning `customSolrKubeOptions`, `solrAddressability` and
`updateStrategy` wholesale. No explicit `FieldOwner`/`FieldManager` is set
anywhere in `controllers/`, so the default manager name is used.
## Impact
Any Helm 4 user whose chart manages SolrCloud resources cannot run `helm
upgrade` without `--force-conflicts` (or `--server-side=false`).
`--force-conflicts` is a reasonable workaround — the chart arguably should own
what it declares, and the operator re-applies its defaults on the next
reconcile — but it has to be discovered the hard way, and forcing conflicts
globally is a blunt instrument for users who have other reasons to care about
ownership.
This likely does not affect ArgoCD users, which defaults to client-side
apply, though I have not tested Argo with server-side apply enabled.
## Suggested fix
Persist the defaults with a server-side `Apply` under an explicit field
manager so the operator only claims the fields it actually sets, rather than
the whole spec. Alternatively, stop writing defaults back into the spec at all
and keep them in memory for the duration of the reconcile, which would avoid
the ownership question entirely — though that is a larger change and would
alter what users see in `kubectl get solrcloud -o yaml`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
