Snapshot of a bootable volume (created without using image) goes into error state
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
Fix Released
|
High
|
Pranali Deore | ||
Juno |
Won't Fix
|
Undecided
|
Pranali Deore |
Bug Description
If an empty volume is created without using image and updated to set as bootable, Then snapshot of this volume goes into error state. This issue affects both V1 and V2 APIs.
Steps to reproduce:
1. Create a non-bootable volume.
$ cinder create --name test_vol 1
2. Update volume to bootable.
$ cinder set-bootable <volume_id> True
3. Create volume snapshot.
$ cinder snapshot-create <volume_id> --name test_vol_snap
4. Show volume snapshot list.
$ cinder snapshot-list
And you’ll find volume snapshot is in “error” state.
cinder-volume logs:
2015-01-22 06:22:54.783 ERROR cinder.
42b35224f] Failed updating 44ecef25-
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.783 TRACE cinder.
2015-01-22 06:22:54.839 ERROR oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
2015-01-22 06:22:54.839 TRACE oslo.messaging.
Changed in cinder: | |
assignee: | nobody → Pranali Deore (pranali-deore) |
Changed in cinder: | |
milestone: | kilo-2 → kilo-3 |
Changed in cinder: | |
status: | Fix Committed → Fix Released |
Changed in cinder: | |
milestone: | kilo-3 → 2015.1.0 |
So if we were to catch this exception and continue, the snapshot would be created without updating it with glance metadata. Later on if an end user creates a volume from that snapshot, it will not automatically be set as bootable because we determine it's bootable automatically because it has glance metadata. Does it make sense when the volume is set to bootable via Cinder API to set some glance metadata?