OpenStack Cinder CSI 2.36.2 - Chart Release With Sparse Notes

cloud-provider-openstack published openstack-cinder-csi-2.36.2 on July 31, 2026. The release presents the Cinder CSI chart for OpenStack, while its notes provide no component level change list for operators to evaluate.

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

The complete release note is one line: Cinder CSI Chart for OpenStack. It identifies the release as chart related. It does not say which templates, default values, container images, permissions, or dependencies differ from the preceding release.

That absence is the central operational detail. No pull requests, commits, fixes, configuration keys, or migration steps are cited. The page also makes no claim about provisioning, attachment, expansion, snapshot, or deletion behavior. Those paths matter to data platforms, but none can be described as changed from the supplied notes.

This is not evidence that the artifact is identical to an earlier version. It means the summary cannot support a more specific claim. Teams running databases, queues, or pipeline state on Cinder volumes should treat the tag as a review boundary, not as proof of a particular reliability or compatibility fix.

Four facts are available from the release record:

  • The version boundary is openstack-cinder-csi-2.36.2.
  • GitHub records publication at 2026-07-31T15:11:57Z.
  • The release is final, not a release candidate, beta, or alpha.
  • Its stated scope is the Cinder CSI chart for OpenStack.

That is enough to identify the artifact and its release status. It is not enough to identify changed defaults, affected Kubernetes versions, required OpenStack services, or an upgrade path. In particular, the final release flag says nothing about the size or risk of the underlying diff.

For platform teams, this distinction is useful. A stable release marker can enter an artifact catalog or change review, but production approval still needs evidence from the chart and rendered manifests. The release summary does not provide that evidence itself. It also gives reviewers no stated reason to prioritize this tag over an already tested deployment.

Before promotion, compare this tag with the version currently deployed. Check image references, permissions, service accounts, secrets, probes, resources, and StorageClass parameters in the resulting manifests. Any difference found there comes from the artifact review, not from the published note.

The validation scope should follow the storage operations used by the cluster. At minimum, exercise provisioning, pod attachment, mount, restart, and deletion in a staging environment. Add expansion and snapshot tests where those capabilities are enabled. For data pipelines with persistent checkpoints or local staging data, verify recovery after pod rescheduling as part of the same gate.

No breaking change or migration procedure is documented, so there is no release specific upgrade sequence to repeat here. Operators should not interpret that silence as a compatibility guarantee. The conservative reading is narrower: the project published a final Cinder CSI chart tag, and detailed change analysis remains with the consumer.