janhoy commented on issue #851: URL: https://github.com/apache/solr-operator/issues/851#issuecomment-6653748890
Thanks for checking. I think everything is better than the stale pravega operator. So I started thinking about how much of a "drop-in" upgrade this really is and what could break for users and what is manual vs can be automated. A clean new install is not problematic, but upgrading can be. I challenged ๐ค Claude and this is the result: ## Upgrade sequence: pravega โ adobe Zookeeper Operator **[manual]** you do it ยท **[auto]** the operator does it ยท **[code]** does not work this way in today's operator โ needs a change first. ### 1. Install the new CRD 1. **[manual]** If you manage CRDs yourself (the default, `zookeeper-operator.crd.create: false`): apply the v1.0.0 bundle as you would for any Solr Operator upgrade โ `kubectl replace -f https://solr.apache.org/operator/downloads/crds/v1.0.0/all-with-dependencies.yaml`, or `kubectl apply --server-side --force-conflicts`. It now carries the adobe CRD. Additive (`spec.logging` is the only new field, `status` unchanged), no restart, safe well ahead of the rest. Not plain `apply`: the CRD is ~480 KB and client-side apply exceeds the 262 KB annotation limit. 2. **[auto]** If you let the chart manage CRDs (`crd.create: true`): nothing to do, the chart upgrade installs it. Argo CD users should keep `crd.create: false` and use the bundle instead โ adobe's CRD template carries no `argocd.argoproj.io/sync-options: Replace=true`, so Argo will client-side apply it and fail on size. ### 2. Swap the operator, ZK image untouched 3. **[manual]** Upgrade the solr-operator chart to v1.0.0 with the ZK image left exactly as it is. Only the operator pod changes; ZK pods are untouched. 4. **[manual]** If you manage RBAC yourself (`rbac.create: false`), add `coordination.k8s.io/leases` โ adobe leader-elects via Leases where pravega used a ConfigMap lock. Also note any `zookeeper-operator.hooks.*` values are now ignored, and `helm uninstall` of that release no longer refuses while ZookeeperClusters still exist. 5. **[auto]** **[code]** The new operator adopts each existing `ZookeeperCluster` unchanged, keeping its live image repository and tag. Today the operator can blank the tag, after which adobe fills in its own default against the pravega repository โ `pravega/zookeeper:3.9.6-0.2.15-adobe-20260924`, which does not exist. Until that is fixed, pin `zk.provided.image.repository` and `.tag` on every SolrCloud before step 3. 6. **[auto]** The operator adds `logback.xml` and `logback-quiet.xml` to each ZK ConfigMap. Inert at the default `INFO`/`text` logging โ the pod template does not change, so no rolling update. 7. **[manual]** Verify before going further: the operator pod has *acquired leadership* (not merely `Running`), every `ZookeeperCluster` is `Ready`, `status.currentVersion` is unchanged, no `Upgrading` or error condition. ### 3. Move to the adobe ZK image 8. **[manual]** Flip the image one cluster at a time via `zk.provided.image.repository` and `.tag` on the SolrCloud. Editing the `ZookeeperCluster` directly does not stick โ the solr-operator reasserts the repository on every reconcile. This is the step that rolls pods; standard ZK rolling-upgrade care applies, and a snapshot or backup is cheap insurance here rather than at step 1. 9. **[auto]** The zk-operator rolls the StatefulSet, then sets `status.currentVersion` and clears `targetVersion`. A pod taking over 10 minutes to go ready trips `UpgradeFailed`, which adobe โ unlike pravega โ retries and self-clears. 10. **[manual]** Confirm `status.currentVersion == <new tag>` and `Upgrading=False`. Do not compare against `targetVersion`; it is reset to `""` on completion. Steps 1-7 are reversible: the older CRD is a subset and the pravega operator ignores `spec.logging`. Step 8 is the point of no easy return. --- So I'd be positive to moving to adobe from v1.0.0. The only competing option, in my mind is SIP-14 (https://issues.apache.org/jira/browse/SOLR-15636) which will let Solr-Operator manage embedded Zookeepers. But it won't materialize in Solr until earliest 11.0 and so is likely a longer term solution that won't answer the needs of Solr 9.x and 10.x users. -- 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]
