cloud-provider-openstack 2.36.1 - Helm Chart Release With Sparse Notes

cloud-provider-openstack published openstack-cloud-controller-manager-2.36.1 on July 25, 2026. The single documented outcome is an OpenStack Cloud Controller Manager Helm chart release, with no individual fixes, configuration changes, or migration steps identified in the notes. This is a final release, not a prerelease.

The full release notes and downloads are on the GitHub release page.

The published note contains one line: Openstack Cloud Controller Manager Helm Chart. That narrow statement supports three concrete conclusions. The release is scoped by its name to the controller manager chart, the published tag is openstack-cloud-controller-manager-2.36.1, and GitHub marks it as a final release rather than an alpha, beta, or release candidate.

The source does not say that the controller binary changed. It also does not identify a corrected template, a changed default, or a dependency update. The tag name matters because it narrows the published scope to the controller manager chart. It should not be read as a change statement for every component in the repository.

For platform teams, that means the release is a versioned chart publication, not a usable change log. It can be recorded in an artifact inventory, but the note alone cannot support a risk assessment for a production Kubernetes rollout.

No changes are listed for chart values, rendered Kubernetes objects, container image references, command arguments, RBAC rules, or secret and configuration references. The notes also make no claim about Kubernetes compatibility, OpenStack API behavior, security fixes, performance, or deprecated settings.

Those omissions matter for clusters that host data services. A controller manager deployment sits in the control plane path used to reconcile OpenStack infrastructure with Kubernetes objects. Even a small chart default change can alter scheduling constraints, credentials wiring, permissions, or rollout behavior. None of those changes are documented for 2.36.1, so none should be attributed to this release without a separate manifest comparison.

The absence of detail is not evidence that the release is unsafe. It is evidence that the release page does not provide enough information to classify the upgrade. Operators should keep that distinction in incident and change records.

Before promotion, compare the rendered 2.36.1 manifests with the version currently deployed. Review the Deployment, ServiceAccount, RBAC objects, image reference, command arguments, environment variables, volume mounts, node placement, and update strategy. This establishes the actual deployment delta that the release page omits.

Run the comparison with the same values and rendering path used by the cluster. A comparison based on chart defaults can hide changes introduced by production overrides. If the output differs, trace each change to the packaged chart before approving it.

Use a non production cluster for the first rollout. Check controller startup, leader election, reconciliation errors, and Kubernetes events before widening exposure. Because the notes provide no breaking change or migration guidance, the release should not be treated as either automatically compatible or automatically risky. The evidence has to come from the rendered manifests and observed controller behavior.