kubernetes/kops · error
Volume.RenderOpenstack: %v
Error message
Volume.RenderOpenstack: %v
What it means
getStorageAZFromCompute (upup/pkg/fi/cloudup/openstack/availability_zone.go:64) maps a Nova compute availability zone to a Cinder storage availability zone by listing block-storage AZs. When the underlying ListAvailabilityZones call fails for any reason (list or extract failure, auth, endpoint, timeout), the error is re-wrapped with the prefix 'Volume.RenderOpenstack:'. The prefix is historical/misleading — the failure occurs while resolving storage AZs, not during volume rendering itself.
Source
Thrown at upup/pkg/fi/cloudup/openstack/availability_zone.go:64
if err == nil {
err = wait.ErrWaitTimeout
}
return azList, err
}
return azList, nil
}
func (c *openstackCloud) GetStorageAZFromCompute(computeAZ string) (*az.AvailabilityZone, error) {
return getStorageAZFromCompute(c, computeAZ)
}
func getStorageAZFromCompute(c OpenstackCloud, computeAZ string) (*az.AvailabilityZone, error) {
// TODO: This is less than desirable, but openstack differs here
// Check to see if the availability zone exists.
azList, err := c.ListAvailabilityZones(c.BlockStorageClient())
if err != nil {
return nil, fmt.Errorf("Volume.RenderOpenstack: %v", err)
}
for _, az := range azList {
if az.ZoneName == computeAZ {
return &az, nil
}
}
// Determine if there is a meaningful storage AZ here
if len(azList) == 1 {
return &azList[0], nil
}
return nil, fmt.Errorf("no decernable storage availability zone could be mapped to compute availability zone %s", computeAZ)
}
View on GitHub (pinned to 4c8573c808)
Solutions
- Inspect the wrapped inner error after 'Volume.RenderOpenstack:' — it names the real cause (list vs extract vs auth)
- Verify the Cinder volumev3 endpoint exists for the region: openstack endpoint list --service volumev3
- Re-check credentials/scopes (OS_USERNAME, OS_PROJECT_NAME, OS_REGION_NAME); ensure the project can list availability zones
- Retry cluster creation if the inner error indicates a transient Keystone/Cinder failure
Defensive patterns
Strategy: try-catch
Validate before calling
// pre-check: block storage client resolvable and AZ list obtainable
azList, err := c.ListAvailabilityZones(c.BlockStorageClient())
if err != nil {
return fmt.Errorf("pre-check storage AZ failed: %w", err)
}
if len(azList) == 0 {
return fmt.Errorf("no storage AZs visible to this project")
}
return nil Try / catch
az, err := c.GetStorageAZFromCompute(computeAZ)
if err != nil {
var gerr gophercloud.ErrDefaultResponse
if errors.As(err, &gerr) && gerr.Actual.StatusCode == 401 {
return fmt.Errorf("re-authenticate: %w", err)
}
return fmt.Errorf("storage AZ resolution failed: %w", err)
} Prevention
- Verify Cinder access (`openstack availability zone list --volume`) before running kops
- Confirm the volumev3 endpoint exists for the target region
- Check token scope grants visibility of block storage AZs
- Watch for transient Keystone outages during cluster operations
When it happens
Trigger: GetStorageAZFromCompute is invoked during OpenstackVolume rendering; the wrapped error surfaces when c.ListAvailabilityZones(c.BlockStorageClient()) returns an error — i.e. the inner 'failed to list storage availability zones' or 'failed to extract storage availability zones' errors, auth token rejection, or a missing/broken volumev3 endpoint.
Common situations: Cinder service not deployed in the region; wrong OS_* environment credentials so the token lacks block-storage access; the volumev3 endpoint missing from the service catalog; Keystone outage; any transient API error that exhausts the read backoff retries.
Related errors
- no decernable storage availability zone could be mapped to c
- failed to extract storage availability zones: %v
- error building cinder client: %w
- error describing volumes: %v
- error deleting volume: %v
AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05).
Data as JSON: /api/errors/5ba518084ac236c7.
Report an issue: GitHub.