----- Original Message -----
From: "Neal Gompa" <ngompa13(a)gmail.com>
To: gmail(a)yudocaa.in
Cc: coreos(a)lists.fedoraproject.org, "Fedora Infrastructure"
<infrastructure(a)lists.fedoraproject.org>
Sent: Sunday, July 22, 2018 10:06:01 PM
Subject: [CoreOS] Re: Migrating from fedimg to ore
On Sat, Jul 21, 2018 at 10:50 PM Sayan Chowdhury <gmail(a)yudocaa.in> 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!
Unfortunately I have to second this opinion. I don't believe that Go is ready to be
used for any core infrastructures pieces in Fedora(where it could be avoided) yet. I would
love to recommend it as golang maintainer, but I can't.
Go is unfortunately not even fully ported to all supported architectures in Fedora now,
although with drop of ppc64 in F29 it will become true. But if we start using Go for core
infrastructure pieces(koji, compose, repo, image,... level) it will mean IMHO steep
increase in amount of effort required to port Fedora to new architectures, due to need to
have port of Go first. This could deeply impact ports that are worked on now, like one for
RISC-V(no Go there, yet).
IMO I it would be good to take this in to account when deciding on this.
JC
> _______________________________________________
> CoreOS mailing list -- coreos(a)lists.fedoraproject.org
> To unsubscribe send an email to coreos-leave(a)lists.fedoraproject.org
> 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/coreos@lists.fedoraproject....
>