volume glance metadata not included in backups.
Bug #1137908 reported by
Dermot Tynan
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
Fix Released
|
Medium
|
Edward Hope-Morley |
Bug Description
The Cinder boot-from-volume system retains the Glance metadata in the volume_
If you back up a volume and then restore from that backup to a new volume, the Glance metadata is no longer available, and the restored volume will not be marked as bootable.
Changed in cinder: | |
status: | New → Confirmed |
Changed in cinder: | |
milestone: | none → havana-rc1 |
Changed in cinder: | |
milestone: | havana-rc1 → icehouse-1 |
Changed in cinder: | |
assignee: | nobody → Edward Hope-Morley (hopem) |
status: | Confirmed → In Progress |
Changed in cinder: | |
milestone: | icehouse-1 → icehouse-2 |
Changed in cinder: | |
importance: | Undecided → Medium |
Changed in cinder: | |
milestone: | icehouse-2 → icehouse-3 |
tags: | added: backup |
Changed in cinder: | |
status: | Fix Committed → Fix Released |
Changed in cinder: | |
milestone: | icehouse-3 → 2014.1 |
To post a comment you must log in.
For normal metadata, this can be handled by storing the metadata with the backup in swift during creation, and restoring during a restore operation. The metadata can either be added to the existing backup metadata file or in a separate file. I don't think there is any good reason not to add it to the existing backup metadata file. There may be some metadata that should be excluded from this process if it doesn't apply to anything but the original volume.
For the glance metadata, the solution is not as trivial. The glance metadata, particularly the billing metadata, needs to be stored in a way that it cannot be tampered with by the user (since some of the metadata relates to licensing and so on). Volume backups are stored in user's space in swift and can thus be modified by the user, precluding us from using the same solution as for normal metadata. There are a number of potential alternatives detailed below,
1. If possible with keystone, during backup the glance metadata could be signed with a credential associated with the openstack administrator and then written with the backup in the normal way (either to the existing backup metadata file or to a separate file). On restore, the signature could be verified and if the metadata has been found to have been tampered with, either the restore fails or the glance metadata is omitted from the restore.
2. The backup process could be modified to backup the glance metadata to a separate area of swift, inaccessible to all but administrative users. During the restore, the data could be re-read from there.
3. During a restore, the glance metadata for the original volume could be re-read from the database for the original volume and copied/associated with the new volume. This obviously has the limitation that the glance metadata is not "backed up" outside of the volumes database and will thus be lost in the event of a catastrophic failure of the cluster (which the redundant backup on swift would hopefully survive). Is that a problem or is the glance metadata inherently tied to a single openstack system anyway?
Approaches 1. and 2. may also be insufficient to handle a restore to an entirely new openstack system unless sufficient data is backed up to allow administrator credentials to be restored/ reconstructed on the new system (although again 1 has the benefit that digital signature verification could be performed with a copy of the administrator's public key, which could be stored with each backup).