Hybrid Manager operator 2.3.0 release notes v2

The operator now periodically redeploys an installation that has finished installing or upgrading, so that any resource of a component that was deleted outside the operator is recreated. Previously, a resource deleted by hand stayed missing indefinitely. This pass only recreates missing resources and doesn't revert a resource you edited; as before, an edited resource is overwritten the next time its component is deployed, for example during an HM upgrade or when you change its parameters. The operator records a Drifted warning event naming the component whose resources it recreated, or a DriftCheckFailed warning when the redeploy couldn't run.

status.scenarios records the scenarios for the Hybrid Manager version the operator last installed or upgraded to: that version, the scenario names it defined, the dependencies between them, and the installed set. Read it with kubectl get hybridcontrolplane edbpgai -o yaml to see which scenarios are installed and which names the target version knows, instead of inferring both from spec.scenarios.

You can now size the container of the jobs the operator runs during an HM upgrade with the upgrade_job_cpu_request, upgrade_job_cpu_limit, upgrade_job_memory_request, and upgrade_job_memory_limit global parameters. They default to 50m and 1 for CPU and to 128Mi and 1Gi for memory, and when you set one half of a pair past the other's default, that default follows it — a request above the default limit raises the limit, a limit below the default request lowers the request. A value that isn't a Kubernetes quantity greater than zero, or a request above the limit you set for it, is rejected at admission.

The operator reads the default object storage credentials from the edb-object-storage secret in either the default or the edb-system namespace, instead of default alone, so an installation that keeps platform secrets out of default can hold it with the rest of them. Keep exactly one copy: preflight reports the default object storage as Invalid when the secret exists in both namespaces.

The names you can list in spec.scenarios are the ones the Hybrid Manager version in spec.version defines, rather than a fixed list built into the operator. A name made of lowercase letters, digits, and -, up to 63 characters, is accepted even when the target version doesn't define it; the operator then removes it from spec.scenarios and records a ScenariosDropped event. So when an HM version retires a scenario, that version stops installing and reporting it, while earlier versions keep it. A name that isn't well formed, such as the legacy monitoringLogging, is still removed automatically when you apply the manifest, so a manifest carrying one keeps applying as before. Upgrading the operator leaves an existing spec.scenarios as it is, and core is still always installed.

An update that drops a scenario the installation is running from spec.scenarios is rejected, because applying it uninstalls that scenario's components along with the data they hold. The error names the command that confirms the removal — kubectl annotate hybridcontrolplanes.edbpgai.edb.com edbpgai edbpgai.edb.com/confirm-scenario-removal=<names> --overwrite — after which you repeat your change; the operator clears the annotation once the new set of scenarios is installed, so a confirmation doesn't carry over to a later edit. A scenario that another listed scenario depends on isn't treated as removed, because the operator adds it back. If the change reaches the operator without going through this check, the operator still doesn't uninstall anything: it sets the ScenarioRemovalBlocked condition and records a warning event with the same instruction.

Creating a HybridControlPlane under any name other than edbpgai, or creating a second one in a cluster that already holds one, is rejected at admission. Hybrid Manager's components and edbctl address the installation by that name, and a second HybridControlPlane stops the operator from managing either of them. The rule is enforced on create only, so an existing installation under another name keeps working: every update to it returns a warning, the operator records a NonStandardName warning event, and reinstalling as edbpgai is what clears it.

A first installation whose spec.globalParameters.internal_backup_folder already holds objects — anything an earlier Hybrid Manager left in the bucket, not just its database backups — is now refused by preflight instead of installing on top of them. kubectl get preflight -o yaml reports it under status.initializationChecks, naming the folder and how many objects are in it. Empty the folder, or set internal_backup_folder to an unused 12-character value, as a new installation requires.

The beacon_server_replicas parameter of the upm-beacon component must be 0 or 1 where it is set, because that component supports a single replica only. An update that changes it to anything else is rejected, while an installation that already carries another value and leaves it alone gets a warning instead and keeps working.

Fixed a bug where the operator could crash in the middle of an installation or upgrade while logging the deploy output of a component that changes many kinds of resources at once. That output is now logged intact and attributed to the right component.

Fixed a bug where status.components[].version was updated only when a component's content or state changed, so a component that a new Hybrid Manager version ships unchanged went on reporting the version it was first installed at. The status now records the version a component was last deployed at, which is what edbctl hybrid-manager status and kubectl describe hybridcontrolplane show.

Fixed a bug where, after a custom resource definition the operator watches was removed — uninstalling Hybrid Manager removes SPIRE's, for example — the operator logged the same error with a stack trace over and over until it was restarted. It now logs this once at info level, and again only if the definition comes back.

A component suspended with edbctl hybrid-manager suspend-component is now left alone entirely until you resume it, and its entry in status.components[] stays as it was. Resuming it with edbctl hybrid-manager resume-component deploys it as before.