On Sat, Jul 21, 2018 at 10:50 PM Sayan Chowdhury <gmail@xxxxxxxxxx> 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 > - 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? > Is there a good reason to migrate from fedimg to ore instead of implementing what we "like" from ore in fedimg? fedimg is already wired into Fedora Infrastructure, leverages first-party API modules for various provider uploads (esp. AWS), and is actually relatively painless to develop and use. The fact it uses Python is also a huge advantage, since it's easy for people to pick up and develop/contribute. Like most things in Go, the development story is pretty awful, and maintenance of Go software is... not great. Between the lack of versioning and the complete lack of sane dependency management, I am incredibly reluctant to encourage development of tools in Go. As someone who actually _does_ maintain a package in Go and has to deal with its idiosyncrasies on a regular basis, I'd rather not inflict that horror on more people... I do agree that we shouldn't have split maintenance between two tools, though I'd rather see Fedora CoreOS images pushed via fedimg rather than ore. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx/message/KVTCKTICJU3G2QK5ICQ43V4UKFMWTOYO/
