On 07/24/2018 10:57 AM, Neal Gompa wrote: > On Tue, Jul 24, 2018 at 10:50 AM Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote: >> >> >> >> 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 https://lists.fedoraproject.org/archives/list/cloud@xxxxxxxxxxxxxxxxxxxxxxx/thread/7BFM6OBOVUNVM76LOQQYPXFLTRXHYPA2/ > > 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. https://discussion.fedoraproject.org/t/launch-faq-which-platforms-does-fedora-coreos-support/53 >>> >>> 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 Dusty _______________________________________________ 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/S2MRL5P3C7BZ6WUZKA3UFMEA3QSINUFN/
