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

  1. Inspect the wrapped inner error after 'Volume.RenderOpenstack:' — it names the real cause (list vs extract vs auth)
  2. Verify the Cinder volumev3 endpoint exists for the region: openstack endpoint list --service volumev3
  3. Re-check credentials/scopes (OS_USERNAME, OS_PROJECT_NAME, OS_REGION_NAME); ensure the project can list availability zones
  4. 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

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


AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/5ba518084ac236c7. Report an issue: GitHub.