Teach IBM Cloud provider to nuke cidata partition if it lives on the primary disk
jlebon opened this issue · comments
Feature Request
Environment
What hardware/cloud provider/hypervisor is being used to run Ignition?
IBM Cloud
Desired Feature
IBM Cloud has bare metal instance types which reuse the same images normally used for the virtual instance types. To do this, the backend transforms the qcow2 image to raw, copies it to the disk, and then adds a partition at the end of the disk containing an ISO9660 filesystem with label cidata to simulate the same API as the attached CD drive on virtual instance types.
This has implications for Ignition since the config allows modifying the partition table of the primary disk. E.g. a config that uses partition number 5 will reference a yet-to-be-allocated partition number in virtual instance types but a pre-existing one in bare metal instance types. This means for example that wipePartitionEntry would be additionally required.
For consistency, we should have Ignition automatically wipe the partition after it fetched its data. That way, the disk state will be the same regardless of instance type. It also plays into our recent trend to delete user-data on platforms where possible. The data will have to be saved somewhere so that Afterburn can fetch additional information from it. Afterburn will have to be taught to look there.
Other Information
The partition name is cloudinit. The filesystem name is cidata. I'm not sure if the partition UUID is stable or not. The partition type UUID is 0fc63daf-8483-4772-8e79-3d69d8477de4 ("Linux filesystem data").
It's possible that in the future, bare metal instances will also support the user-data being supplied either via a secondary remotely-attached block device, or a metadata server. At that point, we may be able to drop this scrubbing logic.
AIUI this scheme is assuming cloud-init is in the instance, right? Maybe we can attach some metadata do our disk that says not to do this, and suggest provisioning metal instances in a different way?
AIUI this scheme is assuming cloud-init is in the instance, right?
It's reusing "cloud-init" style workflows but relying on the fact that "user-data" in cloud init can be whatever you want it to be, which is where we have the users input an Ignition config.
Ultimately the difference here between IBMCloud Bare Metal and what we are doing for IBMCloud Virtual Servers is just that the cidata filesystem is not a separate device but a partition at the end of the disk (i.e. they only have one device to work with and can't easily attach another).