Mount config drive as loop device to supply data to cloud-init
Current configdrive approach is creating a partition on disk and write config data into it is iso format.
The downsides we've experienced are:
1. Waste disk space to accommodate small amount of data
2. Need a primary partition
For images like coreos, which contains several primary partitions, config drive partition creation will fail due to limited primary partition number
3. For some qcow2 images, somehow the whole disk will be used up although the original image is small, leave no space for config drive partition.
4. See bug https:/
The suggested new approach is:
1. Add an configurable option (configdrive_type) on the ironic side so that users can choose between loop device based config drive and partition based config drive.
2. On the ironic side, pass the option to ironic python agent in "prepare_image" method
3. If ironic python agent receives loop option, it shall do following steps after OS image is written to disk:
a) partx -a $device, discover the new partitions
b) vgchange -ay, discover new volumes
c) check all disk and partition block devices, if the size is greater than 0, try mounting the disk/parition
d) search for "fstab" file in the mounted disk/partition
e) if "fstab" is found, make folder "/etc/cloud/
f) append an entry in "fstab" file
4. After reboot, cloud-init will detect the loop device and load data from it.
Blueprint information
- Status:
- Not started
- Approver:
- aeva black
- Priority:
- Undefined
- Drafter:
- xiaobin
- Direction:
- Needs approval
- Assignee:
- xiaobin
- Definition:
- New
- Series goal:
- Proposed for trunk
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by