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