design-file-based-disks-ownership.rst

Ganeti file-based disks ownership

Contents

• Current state and shortcomings
• Proposed changes
• Implementation details
  • Detach operation
  • Attach operation

This design document explains the issue that emerges from the usage of the detach operation to file-based disks and provides a simple solution to it. Note that this design document applies only to disks of template file and sharedfile, but not gluster. However, for brevity reasons these templates will go under the umbrella term file-based.

Current state and shortcomings

When creating a file-based disk, Ganeti stores it inside a specific directory, called file_storage_dir. Inside this directory, there is a folder for each file-based instance and inside each folder are the files for the instance's disks (e.g. <file_storage_dir>/<instance_name>/<disk_name>). This way of storing disks seems simple enough, but the detach operation does not work well with it. The reason is that if a disk is detached from an instance and attached to another one, the file will remain to the folder of the original instance.

This means that if we try to destroy an instance with detached disks, Ganeti will correctly complain that the instance folder still has disk data. In more high-level terms, we need to find a way to resolve the issue of disk ownership at the filesystem level for file-based instances.

Proposed changes

The change we propose is simple. Once a disk is detached from an instance, it will be moved out of the instance's folder. The new location will be the file_storage_dir, i.e. the disk will reside on the same level as the instance folders. In order to maintain a consistent configuration, the logical_id of the disk will be updated to point to the new path.

Similarly, on the attach operation, the file name and logical id will change and the disk will be moved under the new instance's directory.

Implementation details

Detach operation

Before detaching a disk from an instance, we do the following:

1. Transform the current path to the new one.

   <file_storage_dir>/<instance_name>/<disk_name> --> <file_storage_dir>/<disk_name>

2. Use the rpc call call_blockdev_rename to move the disk to the new path.

3. Store the new logical_id to the configuration.

Attach operation

Before attaching a disk to an instance, we do the following:

1. Create the new path for the file disk. In order to construct it properly, use the GenerateDiskTemplate function to create a dummy disk template and get its logical_id. The new logical_id contains the new path for the file disk.
2. Use the rpc call call_blockdev_rename to move the disk to the new path.
3. Store the new logical_id to the configuration.