Fedora Cloud — Edition, not an Edition, and the future

So, this: fedora-release-identity-cloud says “Cloud Edition”, Cloud has not been an Edition for years was apparently a surprise to people. That’s not… surprising, because sometimes we’re bad at recording decisions and disseminating information.

In this post, I’m going to give some history for the record (expanded from my comment in that bug), and then talk about what I think is necessary for considering a “new” Fedora Cloud Edition.

First, the history

When we (FESCo and the Fedora Board, which was in place rather than the Fedora Council at the time) worked out the Editions part of Fedora.next, we decided (primarily at Flock in Charlotte, but much discussion after) that we wanted three Editions focusing on what we at the time saw as major, broad, use cases. At the time, the “Pets vs. Cattle” metaphor for cloud computing was quite in vogue. Basically, Server was to handle the carefully-curated-individual server case, Cloud the at-scale one, and Workstation to be the personal platform for people developing and running those. See:

and in particular the section “Is three a magic number?”

Also from around that time, on Fedora Cloud in specific:

Key quote:

Josh spoke about the Fedora Workstation product being, in some ways, the most difficult, and my first comment about Fedora Cloud is to joke that it’s the easiest, because we start with the minimal base “and then we’re done!”

But, really, the idea of Fedora Cloud is to see what we can provide beyond that. At DevConf, I mentioned that we were exploring the idea of integrating ostree, and since then, we have agreed and are in (sometimes frantic) progress towards making that one of our key features in Fedora 21. I also talked about a Docker host image as an out-of-the-box sort of solution (a pre-assembled Lego set, if you remember back to Part II of this series). We’ve decided to combine these two things in conjunction with the upstream Project Atomic. That project provides the plans and best practices for running containerized applications, including configuration and orchestration, and Fedora (along with RHEL and CentOS) will provide the actual implementation.

Atomic Host, of course, was succeeded by Fedora CoreOS. You can see that something like Fedora CoreOS this was really always the plan. It just went on a kind of strange journey along the way.

At the time of the transition, the Cloud WG as a separate entity was basically defunct. There are some Cloud WG meetings from the time, but the focus is on Atomic, and the ticket landed in the Atomic WG tracker: Issue #158: Proposed website changes for Cloud Base → Atomic Host switch - atomic-wg - Pagure.io. This might seem a little weird procedurally, but there was not functionally a Cloud group separate from the Atomic group.

After we made that decision, there were enough people (and particularly, Dusty Mabe’s heroic work) interested in keeping a more traditional, non-ostree Fedora Cloud Base Image building and released, so we indeed kept doing it. But this was really minimal effort in Dusty’s vanishing spare time, so things like “we’ll change /etc/os-release” never really happened.

In the years after, we decided, officially, at least twice, to merge Fedora Server and Fedora Cloud (because both groups were basically just one or two overworked people), but never actually did the work of making that happen (same reason, really). See Cloud/Server merge - cloud - Fedora Mailing-Lists for one (short) thread about this.

However, all of this is just historical context. I’m not making an argument, just reviewing how we got here.

I don’t think it necessarily determines whether we should have a Cloud Edition now. We certainly have an active Cloud WG, and an active Server WG. That’s cool, and way better than the place we were at before. I don’t want to break that.

So, what’s next?

Well, Fedora.next was meant to be a five year plan. It’s been more than five years. It’s time for a strategic refresh. In fact, the Fedora Council would probably be meeting about that right now, except… that’s the kind of work that just really really works best if you can get everyone in the room to draft a proposal. I don’t think we can do it as well as a virtual thing. So we’ll need to work on some other things. That was actually going to be a topic at today’s Fedora Council meeting, but we canceled that because of the Fedora Linux 35 Go/No-Go meeting (whooo! :ship: :ship: :ship: :party:).

It’d be nice to have that in place to work with. But it’s pretty clear that computing has changed from where it was five years ago. We can make new decisions and do things differently. As we work on a new main Fedora website, we’re looking at positioning Editions and Spins differently, and that computing landscape change certainly hasn’t made cloud less important. The Fedora.next website refresh definitely reflected “three is a magic number”, but we don’t need to follow that in the same way this time. In fact, see A new conceptual model for Fedora for some early design thoughts on that.

Now, should Cloud be an Edition? Well, maybe. I still strongly feel that each Edition should target a distinct use — and where you deploy it or what it runs on isn’t a difference in use. Like, a theoretical Fedora Mobile Edition… that gets my attention, because it’s clearly a totally different thing from the desktop “client” space that Workstation addresses.

So from my point of view, the first thing that needs to happen is clear articulation of why Cloud and Server should be distinct Editions rather than just different deployment profiles of the same thing. How do the personas of the folks who will run each differ? How does the “market” opportunity differ (and how does it do so in a way that split Editions are best)?

Which brings me to the second thing. The Fedora Server WG recently completed a refresh of the Fedora Server PRD. The Fedora Cloud PRD hasn’t been updated since 2015. When the Board first set this out, the idea was that we would require these to be refreshed annually. In practice, that turned out to be too onerous, so we haven’t held groups to that. But, again, a lot has changed in six — almost seven! — years. It’s definitely time for a refresh (and actually I think this would be a useful exercise for the WG, Edition or not.

Also, of course, we do have Fedora CoreOS, and this should sit alongside and, as an Edition, fit nicely together with that too. (See the Fedora CoreOS PRD).

I want to be very clear: not being an Edition isn’t necessarily bad, nor does it mean we don’t care about it. We have lots of awesome stuff we do that isn’t part of an Edition. Being an Edition means it should fit into the overall story in a particular way. Editions are the Playmobil sets we have at the front of the store (or, if you prefer, pre-assembled, ready-to-play Lego sets). We also have a wonderland of building toys and action figures and everything else once you’re in the door. It’s okay for Fedora Cloud Base Image (or just Fedora Cloud, or whatever) to be one of those other cool toys. Or, maybe a store-window display is the right thing.

This isn’t my decision

So, those are my thoughts, but… let’s all figure out where we want to go here.

I think that in thinking about the first question — what’s the differentiation? — and putting together that document about the goals and distinct problem space and the plan to address it will go a long way towards making the answer obvious. But let’s hear from others on the council, Fedora Cloud WG members, Fedora Server WG members, Fedora CoreOS folks, other contributors, users in general…

And, whatever we do, let’s get to a decision we actually can confidently execute on, so we don’t find ourselves into a similar situation six or seven years from now.


I have just a short comment. Cloud is just, IMHO, too broad. Too many things can be done in the cloud: containers, VM, microservices, and more. Cloud is not granular enough and neither is server, it makes more sense (to me) to have a ‘mininal base’ and putting a new name for it, and both WG can work on it since different fronts.

But again, that’s just my thoughts.

1 Like

It’s not correct to take a prima facie position that Cloud Edition is not an Edition. That burden is wrongly being shifted. Cloud edition images have been continuously produced every fedora release, unlike Atomic Host. And if CoreOS is the replacement for Atomic Host, as the replacement for Cloud edition, why not just keep those things under the Cloud SIG? Why create a new CoreOS working group? The clear answer is, these are separate people and working groups producing separate products. Regardless of some aspirational idea at a brief moment in time that made it into a Fedora Magazine article, Cloud edition has endured. That’s a fact.

Workstation WG hasn’t revised its PRD since 2015 either. And even went so far as to render it a historic and foundational document that won’t be updated again. Cloud SIG has open tickets 342, 343,338 noting updates are neeed in a few areas. If not checking the issue tracker, maybe ask the working group what their status is, rather than assert the product isn’t a product?

Server working group has likewise had ebs and flows of relative activity, just like Cloud. But there’s no question there is an edition being produced. I’m curious why the sudden assertion Cloud Edition is not an Edition.

There’s two changes for Fedora 35 Cloud Edition

Both of them refer to the product “Fedora Cloud Edition”. These changes just happened. This release cycle.


As someone on Cloud SIG, this was both surprising and disappointing. I want to stress that “Cloud is not actually an edition” is not at all an understood or agreed upon thing, neither within our own working group, nor in the wider community that contributes to and uses Fedora Cloud. So at very least, there was a breakdown in comms here, and that sucks, especially this close to the F35 release.

The “should Cloud and Server merge” topic has come up from time to time in the past. I will point out that it’s not just a matter of deployment mechanics. The artifacts produced (and the way they’re tested) between Cloud and Server are significantly different, and leverage different kinds of expertise that historically different groups of people have naturally tended to grativate towards. The way our users leverage the products and what they primarily care about are also different: for example, RAID and complex storage device configs are very important for Server, and less so for Cloud, where often you’ll just have a single drive and things like online shrink might take more prominence. Another example: Server needs to be useful for small-scale “hands on” sysadmin deployments or home server deployments, while Cloud is naturally more suited to large scale deployments that make use of automation and config management, and these can lead to different design tradeoffs.

So I think it’s definitely the case that both Server and Cloud target different usecases, and both warrant being Editions in their own right.

On the Cloud side, we can certainly come up with some more formal usecases and get the PRD updated if that’s desired. Given that we’re not the only ones whose PRD has been languishing, I would recommend making a wider comms push to keep these things up to date if that’s an expectation we’ll want to hold editions to in the future.


Okay, so, again, I want to really stress that this isn’t a judgment or anything. It’s just… the history. The Cloud image hasn’t been on https://getfedora.org/ as an Edition since the switch was made. We’ve not been treating it like an Edition.

Chris, I’m not saying that the Cloud image isn’t being produced. I’m saying “it is not a thing which fit in that part of the Fedora.next strategy which is the Fedora Editions plan”. I think there’s a big risk of talking past each other here, and I don’t want to do that. I hear you saying, basically, “It doesn’t matter what the theoretical strategy is, the people working on it make it an Edition”. (Is that fair? I’m not trying to put words in your mouth.) And, I am very into supporting people working on something in Fedora. That’s arguably the main thing I’m paid to do. Also I like to do it. It’s the way the project is successful. So, yes.

But in that case, what does “Edition” mean? Is it just a label? Or is it a word that means something important, but something important other than the way we have officially been using the term? If so, what?

Davide, I have a similar question for you. What does it mean for you for Fedora Cloud to be, or not be, an Edition?

And let me take what I said about “this isn’t my decision” one step further. We certainly can redefine what we mean by the term, or drop it altogether. The idea wasn’t universally popular when we implemented it, for sure. But, it’s also been very successful. I mean:

… the green (and orange following)… that’s when we launched this. Of course, there were a lot of other things we did, but that was really the big change. This is a plan that worked.

Like I said above, I think it’s a good idea to have segmented, intentional outputs we focus energy on and direct people to as solutions to broad classes of problems. And there’s one version of this where, again like I said, we move forward by figuring out if Fedora Cloud fits into that, and finding the best approach for success even if it doesn’t. But that’s not the only possibility. And, it’s been a while, and you can see the growth from F29+ isn’t what it was initially. So…

I’m open to something else, but I’d like that something else to also be a plan that will work. Help us figure it out, and help us figure out where Cloud fits into it!

I don’t know if this should qualify as an Edition however, I think Fedora needs to rename IoT to IoT/Edge (or perhaps these become 2 separate projects…)

I think Fedora is lacking in its strategic vision around “Edge” - I’m not meaning that as an insult, I just mean it matter-of-fact.

When looking at the System Administration world its clear its splitting into 3 broad areas. The traditional area is (A) General Purpose OS (ie. RHEL, Fedora Server, etc), (B) Cloud (a broad term that can mean anything from AWS, containers, CoreOS, K8s, etc), and most recently (C) Edge

Edge is little more nuanced to define because it is in-fact busy replacing “A”, so the two seem like they are blurred together. Edge computing would have some of the following characteristics:

  • Atomic updates / immutable base file system
  • Integrated ‘snapshots’ of mutable file system for offsite backup (ie. Stratis, btrfs, etc)
  • Encryption at rest, by default, decrypted by Clevis via TPM, Tang, USB, etc
  • Headless and administered via Cockpit / Ansible
  • Apps / Services are primarily deployed via Container
  • Role-based security (ie. SELinux)
  • Assumed VPN / Overlay networking (Wireguard, Nebula, Zerotier, Tailscale, etc)

If you imagine a continuum where “A” is completely hands-on self-administered, and “C” is largely managed via orchestration software, “C” falls somewhere in the middle. Its for the use-cases where you need more flexibility than CoreOS, but less hands-on then Fedora Server. A typical case may be the office file / print server…or more likely the server installed on a customer premise running the app you sold them.

In 5-10 years time I think the percentage of rollouts of “B” and “C” will grow massively, and fresh installs of “A” will diminish. Don’t get me wrong, there will always be a place for a General Purpose server OS. However B+C will outnumber these installs by 9-1.

From the above, you can see how closely related some of these ideas are to Fedora SilverBlue, however Fedora doesn’t yet seem to have defined this vision on the server end.

Fedora IoT is a thing, but frankly I’m confused by who its targeting. If Fedora truly wants to get into the embedded space, its going to take lots and lots of work. The resource constraints, oddball CPUs / hardware is going to make it a slog to push into there. I mean Fedora support for RPI isn’t all that great today (I know this is the result of proprietary Broadcom firmware, but this is my point: All of the embedded world is that way)

Or is “IoT” meant to be “Edge” but just poorly named? (to me IoT means your dishwasher that has a web-interface, whereas Edge is the integrated Point-of-Sale system at the local pizza place).

1 Like

I wasn’t around in 2014 when Fedora.next happened, and I don’t want to presume to have context on that discussion and on the strategy that was implemented there. Instead, I’m going to go with what I understand things to be now (and please correct me if I’m misrepresenting things).

I see an Edition as a primary deliverable for Fedora that addresses a board market segment. Workstation, Server, IoT, Cloud all fit this mold – each covers a distinct market with its own users/usecases/etc that has broad appeal/reach and is mostly non-overlapping.

What Spins and Labs are is… less clear to me if I’m honest. The way we’re presenting them now, Spins are framed as alternative takes on an Edition – specifically, everything I see is Workstation using a different DE. Is “Fedora KDE Plasma Desktop” still “Fedora Workstation” (or a variant thereof), or is it something else altogether? Labs instead are framed as focused remixes (again, of Workstation based on what I see) that target a specific narrow vertical (as opposed to a broad market).

So, back to Cloud. If it’s not an Edition, what is it? It doesn’t seem to fit in the mold of either a Spin or a Lab. It’s also not just a set of “alternative download images”. By which I mean, a Fedora Cloud AMI isn’t just a repackaging of, say, Fedora Server or of another Edition to run on AWS. It’s a distinct product, with its own design choices (say, the two Changes for Fedora 35 that Chris highlighted above), testing and Q&A process (we just did a test day the other week), tooling integration (cloud-init and friends, among others), etc.

To answer your question: Cloud being an Edition to me means that Fedora considers it one of its primary deliverables that addresses a broad market segment we care about. Which… it does. And yes, IMO it definitely should be listed on getfedora.org with equal billing to Workstation, Server and IoT.


Tacking on to what Davide is saying here. I was around in 2014, but I wasn’t digging in with both feet back then. I am now. So +1 to the question Davide’s asking here too. If it’s not an Edition, where does it fit?

Cloud is a base, it has variations that work in different environments, but it supports work that is not related to the “Just enough” position of FCOS. The Cloud working group has a very dedicated range of supporters who find value beyond the requirements of other editions. With the adoption of btrfs in this most recent, uh, edition, there was much stir over how it could fit so well and yet diverge so much from Server goals, further accenting this dividing line. That only highlights the reason I think that it does fit as an Edition. The cloud edition is plastic in a way that is appropriate to match the various virtual environments on which it is capable of running. There’s a lot of work to be explored here and a lot of writing to be done to find that next level: Exactly why I put my name down to help improve the PRD. I personally think we should have a closer relationship to the container images as well, but that is another discussion that only deserves a hint in my opinion that we are beyond the pets vs. cattle metaphor. In 2014 we had lots of multi-cloud aspirations that couldn’t be handled, but they can be now.

I consider the Cloud work to be very much an engaged working group with active results. And yes, there are a number of activities that need to be completed, but Matthew, i can’t help but suspect an ulterior motive under the question. If you were looking to identify the contributors who think themselves ready to take on the responsibility and further the program, then we are here and we are actively ready to work towards clarity with the rest of our friends.

So what does “edition” mean to me? It means that there is a differentiation that requires active maintenance and governance. It fits with a specific environment (virt) or a group of related evolving environments ( kvm, hyperV, VMware, Azure, GCP, EC2) that bring benefit to the Fedora community by way of accelerated adoption. An edition must do so in a way that cannot be simply replicated by another edition. There has to be something evolving and that’s definitely still happening around this world of fail-only architectures we call the cloud. I deal less with the private groups, but there are lots of solutions in that space that I am assured by people in labs and corporations, are actively using the Cloud Edition. I’ll let others speak to that, for now.

Beyond the basic functionality, there are areas of cloud alignment that revolve around support for different management APIs and variations in the way hardware functions in each one. These are all valued functions, like the use of power management for hibernation of cloud instances or the use of management apis at boot, like the Azure open management infrastructure. I think that falls under the cloud working group’s governance.


I admit that the topic of Editions has always been confusing to me, and it seems I am not alone with it. So maybe it is a right time to talk through the overall concept again and get a refreshed understanding?

Worth noting, that I absolutely love the fact that Fedora provides so many opportunities for people to work on so many kinds of projects and products based on its pool of packages. And I think we should encourage the creativity and let people build whatever they like. I think that the role of Fedora Council here is not to restrict the work of community, but to develop some sort of language to describe it.

The idea is that while various groups can do whatever they like, the role of the Project is to help those groups to communicate, show their work and collaborate. Therefore we need some structure for various efforts to simplify the discovery and to promote deduplication of work where possible.

Now, recently I’ve started to think is the hierarchical approach actually the right one for us?

The latest example which triggered that thought was Fedora Kinoite discussion.

We do have Editions and Spins as separate categories now, but are they mutually exclusive? There is obviously a place for a Spin of an Edition. And a variant of a Spin of an Edition with a Profile and built into a certain kind of Format for delivery.

So rather than separate Editions from non-Editions shouldn’t we tag a certain Fedora Thing into some Fedora Edition?

What if rather than separating things into different categories we create some “multi-dimensional space” where we can place things according to multiple criteria?

For example, “show me everything which can be installed on my ARM machine” or “show me everything which uses rpm-ostree technology” seem to be valid questions for me.


I tend to wear my ulterior motives on my sleeve — if I have one, I will say so!

I guess the one feeling I have here that I haven’t said anything about is that we have declined requests to make something an Edition in the past, and we have also asked groups (specifically, CoreOS and IoT) to go through the process we’ve defined. I linked that above but here it is again more explicitly Process for promoting a Fedora deliverable to Edition :: Fedora Docs. To me, the things we’ve described there aren’t just hoops to jump through. They are part of what the term means.

I am, in fact, super-sympathetic to the idea of making Cloud an Edition again. If you remember, this was personally my baby for several years. I just think that it’d be unfair to say that the process now doesn’t apply. I know that you are all doing awesome work, and have great ideas for making Fedora Cloud even better. I don’t think the request to help us document the positioning and road map in order to present the offering more prominently is unfair.

If course, we can update that process, but if we do we should do so intentionally, not out of surprise and communication failures. (Which, yes, we should also work on. There are plenty of places where assumptions are made which we should be more clear about.)

1 Like

I agree this is confusing. We actually decided to do away with the distinction a couple of years ago:

but since it was fundamental to the site layout, it wasn’t so easy to remove the apparent separation. It’s taken this long to get marshaled for the big website refresh that will make that happen in practice.

I would say that the easiest answer to “if it’s not an Edition, what is it?” is “it’s an official Fedora Spin”. That’s a little hit jargony but I think widely understood.

OK, so, this is my other… confusion? concern? perplexity? with @chrismurphy’s response. Cloud isn’t there now, and clearly hasn’t been since 2017. Saying “actually it’s really an Editon!” doesn’t change that. It’s the status quo. What I’m outlining here is the existing process to make the change, and also opening things up to looking at changing the overall approach.

Really, all I want is for things to get better, for users to have a clear path to getting the best solutions for their use cases, and for all of your awesome efforts to get the best and most appropriate showcase.

Two years ago, I was told to wait until the website redesign work was underway (when the whole logo thing started), that’s why I haven’t been pushing it much now. That was, in retrospect, a mistake.

I am grateful for that. I also tend to unmask no matter what.

100% reasonable to make that part of a plan. It shouldn’t be any different. As a working group, we can prioritize that and I think it’s a legitimate ask. And it is expected that the path should evolve.

If you remember, this was personally my baby for several years.

Aha! I see your ulterior motive! You like it too. :sunny: I am glad you reminded us of that. I personally think it’s a treasure and I am happy to make sure it follows the process and work with the rest of the team to help the council have the right content and programs to elect to see this as an edition.

I think this a very reasonable way to view it: Yes, under-the-hood its all just Fedora…and yes you can turn Cloud into a Desktop if you really really wanted to… but that may be difficult given the configuration / architecture assumptions.

Probably Spins + Labs should be consolidated under a specific category (Spins seems more appropriate header, Labs implies other baggage).

Perhaps the conceptual overview is like this:

Editions - Dedicated user-base / use-case that may be mutually exclusive to other Editions (that is Cloud vs Desktop)

Spins - Existing Editions, with known working alt-configurations (ie. Desktop + KDE, or Desktop + Audio App Collection, etc)

I would like to advocate to keep the distinct procedures and the specific label of Edition. The way I read it and follow the discussions over time, the procedure to become an edition and the criteria to remain an edition are intended to give users confidence in a certain quality and long lifetime (overcome the problem of continuity in open source projects). And an edition makes it easier to match the deliverable against your own use case, versus an amorphous distribution.

Spins used to be variations of an edition, and labs are, in effect, non-short-living development projects for specific use cases, which may of may not evolve into one of the other types. For example, ‘Scientific Labs’ can evolve into a workstation spin, or an edition, or a software group, or something else.

1 Like

Oh, also one other bit of history here: we originally used the term “Product”. The idea was: rather than just putting things out there that we hope people might like, we’d actually research needs and develop technical plans to solve problems, as one might do to bring a successful commercial product to market — even though we of course aren’t selling or supporting anything, we still can benefit from that kind of approach. In full disclosure, this may have coincided with me taking this training https://www.pragmaticinstitute.com/course/product/focus/ (which I really liked and still recommend)!

(And, again, I think time has shown that that definitely worked.)

So, see for example this ticket:

Issue #4: proposed general criteria for Fedora products - tickets - Pagure.io

… which is also where we formally agreed on the definition I’m still using in all of the above.

And, again in the interest of transparency, this is the ONE SINGLE TIME Red Hat corporate has gotten really upset with me for something as Fedora Project Leader (both then and since), and it was a minefield I hadn’t even known I was stumbling into.

Part of the story Red Hat tells itself about its own success is that it figured out how to make products from open source projects. This was part of the whole thing of “Red Hat Linux Project” vs RHEL at the dawn of (Fedora) time, and it’s part of how Red Hat still describes what it does to customers who don’t quite get it. Generally, I don’t think people outside of Red Hat – or outside of marketing at least – really make that distinction, but Red Hat feels like it’s not just words but essential to the company’s identity. So, I was like, okay, fine, well, it’s just words to me, so this happened and we ended up picking “Edition” as the term because no one else liked my suggestion of “Fedora Flavors”.

I’m not sure how much I can add to this, but as the person who first proposed the “Fedora Products” split, I can at least try to provide a bit of context.

Back around Fedora 19, the Project was suffering. We were hemorrhaging users to other distributions (in part because of the not-at-all-controversial switches to systemd and GNOME 3). Beyond that, we were getting pressure from inside Red Hat about the value of Fedora as it skewed more and more heavily into a desktop-focused distribution and was therefore looking less valuable as a basis for RHEL.

So I proposed the idea that we would take the idea of Spins and go a bit further with it. The idea was to build the distribution in such a way that we could produce deliverables to address specific needs in the marketplace, rather than being a one-size-fits-few “bag of Lego™ bricks” (as Matthew liked to describe it). In particular, the big change we needed to make (beyond the ability to compose multiple trees) was the ability for different Fedora “flavors” to have different default setups. For example, Workstation and Server groups in Fedora had wildly conflicting perspectives on the default filesystem, SSH server and firewall state (among other things).

I pitched the topic at the first Flock conference in Charlotte, North Carolina in one of the early main-room sessions and it continued into numerous hallway track conversations from there. One of the most important points that was raised was that for this to work, we’d need for the Products (later renamed “Editions”) to serve a specific need. This had to be a meaningful chunk of a marketplace. So we initially decided that we wanted to focus on three main areas, with the option to expand or contract the number of Editions as needed:

  1. The desktop use case - We wanted to ensure that we didn’t lose the loyal users that had stayed with us up to this point, but we also wanted to pick something more focused than “general desktop user”. We settled on the idea of a Workstation Edition that was designed around some common user personas to do work (initially we focused on software development, but later branched out into a somewhat more general space).
  2. The “pets” use case: In the old pets-vs-cattle metaphor, you had some systems (“pets”) that you always care for and keep running for a long time. These would be fundamental to your environment (Domain controllers, Storage servers, databases, etc.) that care deeply about “uptime” and “reliability”. For this, we decided that we would create a Product called “Fedora Server” to address those needs.
  3. The “cattle” use case: These were the short-lived, throwaway instances that could be used for rapid scaling of services. As such use-cases were generally handled in “the Cloud”, we opted to create a Cloud Product that would focus on making Fedora a player in that space.

Over time, the VM-based nature of Cloud computing gave way to containers and Kubernetes, and the perceived value of having a primary deliverable focused on a dwindling use-case was dropping. That was about the time that rpm-ostree was maturing to a point where it could be relied upon for a complete distribution and we opted to switch the “cattle” focus from VMs over to containers and container hosts. Initially, this was Project Atomic until that eventually merged with CoreOS to become Fedora CoreOS.

All of this has been a somewhat long-winded way of saying that the Editions have always been very targeted at filling a specific niche. “Cloud” is too broad of a concept, and it’s part of why we’ve considered numerous times that “cloud images” should just be a delivery artifact of Fedora Server and Fedora CoreOS rather than their own separate Edition.

Cloud images are very valuable to the Fedora Project! We do not want to lose them, nor do I want to suggest that not calling them an Edition means they are unimportant. From my perspective (and how I originally envisioned things), an Edition needs to solve a particular problem. Server for example solves the “I need a secure-by-default platform for running persistent services in my environment”. Workstation solves the “I need a platform that allows me to do my job with a minimum of hassle and a maximum of efficiency” case. But Cloud really only ever existed to provide a minimal base image for building upon.

To use a slightly different metaphor, I think this lines up with how the US Supreme Court decided some important patent cases in the early 2000s. Essentially, they ruled that “you can’t patent something that would not be patentable simply by adding the words ‘on a computer’ at the end of the description.” Essentially, they ruled that the novelty (and therefore patentability) came from the solution that the device/process presented, irrespective of the delivery mechanism. To my mind, this is exactly what Cloud should be: We should have a cloud image for Fedora Server for those who want to run their essential services on a private or public cloud. We should have a cloud image for Fedora CoreOS for people to build their container hosts in a cloud. Maybe we should even have a Cloud Workstation for people who want a centrally managed virtual desktop setup.

I just don’t think that “Fedora Cloud” in and of itself is an Edition. Find a use-case that is exclusively about the cloud (for example, managing and monitoring public, private and hybrid clouds) and build THAT, rather than simply offering a minimal base image. Maybe create and ship Fedora OpenStack, a tool to easily set up your own private cloud. Or Fedora OpenShift: manage containers in the public cloud using Fedora’s exciting new container tools! These ideas are, to me, better examples of what an Edition would be.

Over time, the VM-based nature of Cloud computing gave way to containers and Kubernetes, and the perceived value of having a primary deliverable focused on a dwindling use-case was dropping.

This is a bit of a reductive framing, and one I specifically disagree with. Containers are an important usecase for sure, but one that’s orthogonal to VM-based Cloud, which is still actively used, growing and isn’t going anywhere. There’s plenty of room for both to coexist.

We should have a cloud image for Fedora Server for those who want to run their essential services on a private or public cloud.

But “a cloud image for Fedora Server” is a fundamentally different product from “Fedora Cloud”. Cloud environments have different technical constraints (e.g. around storage and networking), different deployment mechanics, different management tooling and ecosystem integration points and generally different classes of users from traditional servers. This naturally results in a product that makes different choices to better address them, which aren’t necessarily the same choices you’d make if you were optimizing for traditional servers. Why woudn’t that be an Edition in its own right?


I’m suggesting action is what makes or unmakes an edition. A formal process was followed to make Cloud working group and edition. No formal process was followed to unwind them. Editions exist by Council mandate. Marketing strategy, or lack thereof, is not what defines whether something is an edition.

So I am currently stuck on: “cloud is not an edition because the folks involved intended it to no longer be an edition, but cloud cannot now be called an edition either even though folks involved intend it to be an edition.” It’s a double standard. And the inevitable confusion from being loosey goosey about process and setting expectations properly has now ensued, to the point that there isn’t agreement on whether Cloud is or is not an edition.

My view is, since Cloud Edition is being produced and Council hasn’t formally unmade what it made, Cloud Edition exists.

Considering that it’s been 4 years of assumption without process being pointed to why it’s not an edition, on the one hand; and two change proposals following process to evolve, maintain, and reference to the product as Cloud Edition on the other - it’s very curious to me that a bug asserting the edition is not an edition and therefore a blocker is filed, discussed, and voted on, inside of 20 minutes. What is the backstory here?

Per rules of order, the question should not have been asked because it was out of scope for the meeting. The presumption that Cloud edition is not an edition is in dispute and only Council can address the question.