On 07/20/2018 08:15 AM, Sayan Chowdhury wrote:
Last few days, I spent doing a feasibility analysis on the migrating from fedimg to ore, a subproject of mantle to release the Fedora cloud images.
ore/mantle comes from the CoreOS community. mantle is comprised of multiple utility projects to keep the CL bits together.
The workflow for fedimg right now:
- Downloads the raw.xz image
- Uses the ImportVolume AWS API[1] to create a volume via S3
- Creates the snapshot using the earlier created volume
- Registers the AMI of the snapshot provided
- Copies the AMI to other regions and makes the AMI and the snapshot public.
What if we migrate to Ore? The process remain more or less the same except for a few changes:
- Downloads the .qcow2 image
- Once we start using the .qcow2 image we don't need releng to
produce two formats i.e. qcow2 & .raw.xz
I thought we needed raw for some cloud provider? perhaps not.
- Converts the .qcow2 image to .vmdk format image using qemu-img
- Uses the newer supported AWS API i.e. ImportSnapshot which directly
creates the Snapshot uploading the image via S3
Registers the AMI with the snapshot.
Copies the AMI to other regions.
Ore also skips any of the steps already processed which makes it
easier for the AMIs maintainer.
- Ore has a more maintainers than fedimg.
- It's better to focus on a single project than maintaining two.
Two areas where it needs more research
- how do we send out the fedmsg messages when we move to ore
- making the images & the snapshots public.
Thoughts?
All this is in go I assume and not packaged?
I agree it would be nice to have fewer things and more maintainers on those things. :)
kevin