cloud-provider-openstack narrows image architectures and extends builds

cloud-provider-openstack provides Kubernetes integrations for OpenStack, including cloud controller and storage components. This week’s activity narrows image architecture coverage and changes how the project builds its containers. For engineers running data workloads on OpenStack Kubernetes, the practical concern is whether the infrastructure images they deploy still match their nodes and build pipelines.

The removal of armhf from image builds is the clearest compatibility change in the captured activity. A separate restriction on the osbrick sidecar limits that component to amd64 and arm64. Treat these as two distinct changes. The first removes an architecture from the broader image build process; the second defines a narrower architecture set for one component.

For a data platform, this matters below the application image. An ETL worker image can support a node architecture while a required storage component does not. Before adopting images produced by these changes, compare the platforms in each image manifest with the nodes where that component must run. In particular, do not interpret the removal of armhf as removal of arm64. The sidecar commit explicitly retains arm64.

The tradeoff is less architecture coverage for upstream to build and maintain, with fewer deployment options for consumers of the removed targets. The staged material does not establish a build failure rate or explain every dependency behind the decision. It also does not show that existing registry images were deleted. Operators should check the exact image tag they intend to deploy before deciding whether a node pool needs changes.

The project adds Makefile targets for building images across architectures. The Makefile appears in four commits, making it the most frequently touched file in this window. That puts the build entry points near the center of this activity review.

Teams that rebuild provider images for an internal registry should inspect these targets before carrying forward a separate build wrapper. An upstream target may replace some local orchestration, but its name alone is not enough to establish equivalent behavior. Compare the architecture selection, image naming, registry destination, and whether the target pushes artifacts. The staged summary names build-multiarch-image targets without providing their recipes, so it cannot supply a verified command sequence.

This is relevant when a platform team distributes both application images and the storage infrastructure beneath them. If an internal pipeline retains an old platform list, it can request combinations upstream has stopped building. Review the new targets alongside the architecture restrictions before updating that pipeline. Otherwise, adopting the entry point and retaining stale assumptions can produce a build configuration that no longer matches upstream intent.

The Cloud Build timeout change has an exact, visible diff. In cloudbuild.yaml, timeout: 1200s becomes timeout: 2400s. The configured ceiling doubles from 20 minutes to 40 minutes.

That gives a build more time to finish before the timeout terminates it. It also allows a slow or stuck build to occupy the job for longer before that particular limit intervenes. The diff contains no duration measurements, so it supports no claim about faster image production or the amount of extra time a typical build needs. Nothing in this change alters a Kubernetes workload timeout.

For downstream builds, compare this ceiling with any outer CI job limit. A wrapper that still kills its job after 20 minutes prevents the inner build from using the additional allowance. If you adopt the longer limit, keep tracking actual duration and the stage consuming it. A successful build at minute 35 is useful information when planning image promotion, but it would still warrant investigation if the same build previously took ten minutes.

The capture contains nine commits on master, spanning 60 files with 849 insertions and 558 deletions. It includes the 1.37.0 release commit and subsequent release housekeeping. This is an activity snapshot around a release, not evidence that every listed change belongs to the same published artifact.

The Cinder chart metadata, Manila chart metadata, and cloud controller chart metadata each appear in three commits. Those counts identify useful review locations. They do not establish changed chart defaults or storage behavior. Before promoting an update, resolve the chart version and rendered image references against the artifact you actually plan to install.

  • Check architecture coverage for every required infrastructure image. The osbrick sidecar has an explicit amd64 and arm64 restriction; an application image’s platform list cannot answer that compatibility question.
  • Review internal build wrappers against the new Makefile targets and the 40 minute Cloud Build ceiling. Verify both platform selection and the outer job timeout.
  • Keep the release tag separate from later master activity. Use the deployed chart and image references to determine which changes reach a data platform upgrade.