OCCM Helm Chart 2.36.5 Drops Bitnami Common


The cloud-provider-openstack project published openstack-cloud-controller-manager-2.36.5 on 8 September 2026. The tag is the Helm chart for OpenStack Cloud Controller Manager. Chart version is 2.36.5 and appVersion stays at v1.36.0. GitHub’s note is the Chart.yaml description string. The packaged templates drop the Bitnami common subchart and set a stricter container securityContext on the controller DaemonSet.

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

Chart.yaml no longer has a dependencies block. Chart 2.36.4 pulled Bitnami common 2.14.1 only to render common.labels.standard. That helper now lives in charts/openstack-cloud-controller-manager/templates/_helpers.tpl as occm.labels.standard.

occm.labels.standard writes the recommended labels: helm.sh/chart, app.kubernetes.io/name, app.kubernetes.io/instance, app.kubernetes.io/version, and app.kubernetes.io/managed-by. Every template that called common.labels.standard now calls occm.labels.standard. ClusterRole, ClusterRoleBinding, Role, RoleBinding, Secret, Service, ServiceAccount, ServiceMonitor, and DaemonSet metadata all switched.

Helm installs of this chart no longer need helm dependency update against the Bitnami repo. Air gapped render jobs that vendored the common tarball can drop that pin for OCCM. Pulling a whole subchart for five labels was a lot of moving parts for little gain.

Maintainer metadata in Chart.yaml now lists stephenfin at Red Hat. The old Telekom maintainer entry is gone. That is chart identity only. RBAC names and the cloud-controller-manager ServiceAccount are unchanged.

values.yaml now fills in a container securityContext that matches what OCCM actually does. The process talks to the Kubernetes API and to OpenStack (Keystone, Nova, Octavia). There is no guest volume mount path and no kernel module load.

securityContext:
  capabilities:
    drop:
      - ALL
  readOnlyRootFilesystem: true
  seccompProfile:
    type: RuntimeDefault
  allowPrivilegeEscalation: false
  runAsNonRoot: true

Pod level podSecurityContext still sets runAsUser: 1001 and seccompProfile.type: RuntimeDefault. Together with runAsNonRoot: true and allowPrivilegeEscalation: false, the container is much closer to a Restricted profile than the empty {} default that 2.36.4 shipped.

The pod remains outside the Restricted profile. hostNetwork stays true by default. extraVolumes still mounts host paths at /usr/libexec/kubernetes/kubelet-plugins/volume/exec and /etc/kubernetes/pki. Pod Security Admission will keep complaining about those even after this bump. The chart comments that host network is still required when the metadata service is in use (many CNIs still fail on link local addresses) or when the OpenStack control plane sits on a management network that pods cannot reach. If you only run the service controller against Octavia, set hostNetwork: false and switch dnsPolicy to ClusterFirst.

dnsPolicy defaults to ClusterFirstWithHostNet. With hostNetwork: true, kubelet would otherwise hand the process the host resolver. OCCM still needs cluster DNS for the API server Service and for names inside the cluster.

priorityClassName defaults to system-node-critical. If kubelet evicts OCCM under memory pressure, new nodes sit in NotReady because the cloud-node controller never initializes them, and LoadBalancer Services stall in the service controller. That eviction path is worse than a slightly greedier QoS class.

Enabled controllers remain cloud-node, cloud-node-lifecycle, route, and service. The image is still registry.k8s.io/provider-os/openstack-cloud-controller-manager. image.tag is empty, so the DaemonSet falls back to appVersion v1.36.0.

A new helper occm.labels.matchLabels emits only app.kubernetes.io/name and app.kubernetes.io/instance. The optional ServiceMonitor spec.selector uses that helper.

Matching on helm.sh/chart or app.kubernetes.io/version is a scrape outage waiting to happen. Those labels change when chart version or appVersion bumps. Prometheus Operator then drops the target after helm upgrade, and OCCM metrics go quiet until someone notices.

The Service and the DaemonSet pod template still use the older app / release / component labels via occm.controllermanager.matchLabels. Changing those selectors would break a rolling upgrade of an existing DaemonSet. The chart leaves that work for a later major version.

When serviceMonitor.enabled is true, the container binds 0.0.0.0:10258 and adds --authorization-always-allow-paths=/metrics. Otherwise --bind-address stays 127.0.0.1. The scrape endpoint is still HTTPS with insecureSkipVerify: true on a 30s interval.

This tag bumps the chart on the same v1.36.0 image. Binary behavior stays at v1.36.0 unless you set image.tag.

Check custom values before helm upgrade:

  • Overrides of securityContext that add capabilities or set readOnlyRootFilesystem: false still win. If you were copying the old empty {} default, you now inherit the tight defaults. Confirm the controller still starts, especially if something injects files onto the root filesystem.
  • dnsPolicy and priorityClassName are now explicit. A values file that omitted them will pick up ClusterFirstWithHostNet and system-node-critical.
  • Drop the Bitnami common chart from any vendored chart lock used for this release.
  • ServiceMonitor users should confirm the scrape target still matches. The selector is now name plus instance only.
  • DaemonSet match labels stay on the old app / release / component set. Skip a label migration on this bump.

The GitHub notes have no migration guide. Diff your rendered manifests against 2.36.4 before rolling control plane nodes.