On 07/24/2018 10:57 AM, Neal Gompa wrote:
On Tue, Jul 24, 2018 at 10:50 AM Dusty Mabe
> On 07/22/2018 04:06 PM, Neal Gompa wrote:
>> Is there a good reason to migrate from fedimg to ore instead of
>> implementing what we "like" from ore in fedimg?
> Mostly the fact that with the acquisition of CoreOS Inc we have more
> people that know and maintain ore than fedimg (where sayan was really
> the only person who knows fedimg). ore also has the ability to upload
> to many more clouds than just AWS, which I don't think is something we
> ever had in fedimg.
Well, Fedora itself doesn't really support cloud providers other than
AWS. For example, we don't have the required tooling for GCE packaged
in Fedora, so even if we wanted to make GCE images, they won't work. I
found this out while actually trying to get Fedora working on GCE for
Snappy's CI. I did make rudimentary packages for their tools to make
things work, but it's not in good enough shape to be in Fedora proper.
If we want to support more cloud providers, that's a different story,
and I doubt it'd be that difficult to add to fedimg. If we were
interested in making official GCE images, I'd be happy to help with
fedimg and other things to get that going.
That's awesome! I know jdoss was interested in helping make sure we
get more regular releases of the cloud base image as well. See
The lack of people working on things is a function of the lack of
priority on the cloud for Fedora. IMO, we've been chasing all this
Atomic stuff that most of the Cloud stuff has rotted. Do we care now?
As stated in the original FAQ, Fedora CoreOS will target many cloud
providers. I'm hoping this means, by association, issues we had with
getting the Fedora Cloud base image into various clouds will no longer
be a problem.
>> 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 agree Go can be a pain. Despite that I think this is a good starting
> point for now because we get the added functionality ore currently has
> without doing a bunch of new development. For now I think we have other
> "bigger fish" to go after.
If we have bigger fish to go after, why are we bothering with this
conversation at all?
That's my opinion :) - IOW I'm +1 for ore because it has all the functionality
we already need and allows us to concentrate on other issues we have to knock
out for an initial release of FCOS. Are we causing ourselves issues by taking
on technical debt ? Maybe. I personally prefer dynamic/shared lib/interpreted
languages as well because of dep issues with Go, but i'm trying to be practical.
/me wishes we had a team of people for solving the packaging issues around Go/Rust