Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Teach IBM Cloud provider to nuke cidata partition if it lives on the primary disk #1599

Open
jlebon opened this issue Apr 6, 2023 · 2 comments
Labels
jira for syncing to jira

Comments

@jlebon
Copy link
Member

jlebon commented Apr 6, 2023

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.

@bgilbert bgilbert added the jira for syncing to jira label Apr 13, 2023
@cgwalters
Copy link
Member

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?

@dustymabe
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
jira for syncing to jira
Projects
None yet
Development

No branches or pull requests

4 participants