Identifying Fedora media

EDIT: With the immensely greater wisdom that comes with being a day older, I'm now more or less convinced this whole post is wrong. But instead of editing it and confusing people who read the original, I've left it here and written a follow-up. Please read that.

Thanks to mizmo for inspiring this post.

On 'Fedora Atomic' as a flavor

Mo wrote that the Cloud WG has decided that, from Fedora 24 onwards, they will focus on Atomic-based images as their primary deliverables. In response to this, Mo and Matt Miller were kicking around the idea of - as I understand it - effectively rebranding the 'Cloud' flavor of Fedora as the 'Atomic' flavor.

This immediately struck me as problematic, and after a bit of thought I was able to identify why.

The current Fedora flavors - Cloud, Server, and Workstation - can be characterized as contexts in which you might want to deploy Fedora. "I want to deploy Fedora on a Cloud!", or "I want to deploy Fedora on a Workstation!", or "I want to deploy Fedora on a Server!" Yes, there's arguably a bit of overlap between 'Cloud' and 'Server', but we do have a reasonable answer to that ('Cloud' is about new-fangled cattle, 'Server' is about old-fashioned pets).

Atomic is not a context in which you might deploy Fedora. You can't say "I want to deploy Fedora on an Atomic!", it just doesn't work. Atomic is rather what I'm referring to as a deployment method. It's a mechanism by which the system is deployed and updated. Another deployment method - the counterpart to 'Atomic' - would be 'RPM'. Atomic happens to a deployment method that's quite appropriate for Cloud deployments, but that doesn't mean you can just do s/Cloud/Atomic/g and everything will make sense.

So for me the idea is simply not conceptually compatible with how we define the flavors. We might even, for instance, want to build 'Atomic Workstation' instances of Fedora. I believe there's even been interest in doing that, before.

Mo's post suggests that we might treat 'cloud' rather like we currently treat 'ARM', as a sort of orthogonal concept to the flavors, with a kind of parallel identity on the download site. I would suggest that it would make more sense to do exactly the opposite: it's Atomic that should be given a sort of parallel existence. We might want to have an Atomic landing page which focused on all the Atomic implementations of Fedora. But it's not, for me, a flavor.

Thinking about identifying Fedora media

So you might be aware, I have a little project called fedfind, which is broadly about finding Fedora media. About half of the work fedfind does is finding the media. The other half of the work it does is identifying them. Fedora 23 Beta RC1 has 59 'images', approximately (depending on whether you count boot.iso files separately from their hardlinked alternate names). Trying to come up with a set of attributes that would serve as a sort of conceptual framework for identifying images has been an interesting (and ongoing!) challenge. In fact, as a result of thinking about the 'Atomic' proposal, I've just revised fedfind's approach a little. So, I thought I'd write quickly about how fedfind does it.

I first thought about this stuff before starting fedfind, when I wrote an image naming policy. fedfind initially followed that policy precisely. Events have overtaken it a bit, though, so the current implementation isn't quite the same. And today, I've added the deployment method concept as an attribute in fedfind's system. The changes described here are sitting in my editor right now, but should show up in git master soon!

Some of the attributes fedfind uses are fairly obvious (arch is just the arch, and release, milestone and compose are just version identifiers), so I'll focus on the more interesting ones. fedfind provides a couple of properties - desc and shortdesc - for images which can be used as descriptions; taken together, all these properties allow us to give a unique identity to every one of the 59 images in 23 Beta RC1, as well as covering all historical releases (in my checks anyway). shortdesc contains payload, deployment (if not 'rpm'), imagetype, and imagesubtype (if present); desc adds arch. For any given release's images, there should be no duplicated descs.

imagetype and imagesubtype

These identify the 'type' of the image specifically. What's the difference between the Fedora 22 x86_64 Workstation live image and the Fedora 22 x86_64 Workstation network install image? They're the same version, same arch, same payload (see below) - but different imagetype. A few images also have an imagesubtype. For instance, we provide two types of Vagrant image, for use with libvirt and virtualbox; these have vagrant as the imagetype and libvirt or virtualbox as the imagesubtype.

flavor, loadout and payload

It's intended that most every fedfind image should have either a flavor or a loadout; for convenience, whichever one it has is also available as the payload. This can be thought of as 'what's the actual content of the image'. Flavors are workstation, server, and cloud; loadouts are things like kde, xfce, mate etc. (for live images and ARM disk images), plus some oddballs. There is a minimal for ARM disk images, and source and desktop for older releases where we had source CDs/DVDs and 'Desktop' live images. There's one fairly special case: DVDs and network install images, boot.isos, and current nightly images have no flavor or loadout, but have the special payload generic.

Current fedfind releases have a concept of subflavor, which is only used to give some Cloud images a subflavor of atomic. After thinking about this (above) it seemed completely wrong, so today I've changed things around so the subflavor property is gone, and instead we have...


As discussed above, this is the 'deployment method'. Currently it's either rpm or atomic.


Matthew Miller wrote on 2015-09-18 16:06:
My initial thought and proposal was along the lines of what you're saying — Atomic with its own new parallel existence. But Mo talked me out of it. :) I do disagree with the description of the flavors as "deployment contexts". Well, or maybe not quite disagree, depending on how we define terms. What if you replace "deploy Fedora on..." with "Deploy Fedora as..."? In that case, it's "I want to deploy Fedora as a [developer's] workstation OS"; "I want to deploy Fedora as an [easy-to-manage, cockpit-controlled] server OS"; and "I want to deploy Fedora as platform for running Atomic Apps [containers!]"
adamw wrote on 2015-09-18 16:35:

Yeah, I don't know, now I look at the Atomic site again in detail it seems even fuzzier. Atomic is really emphasizing the 'we're a container deployment platform!' angle more now than I remember; I was still kinda going off the (older?) angle that emphasized the OSTree stuff. I mean, I guess in a sense it's really just marketing sprinkles - you can run Kubernetes and Docker and so on on an RPM base too, the unique thing about Atomic really still is OSTree. But the way they're choosing to present the project obviously indicates their intent in developing it, and that they do kind of want people to think of "an Atomic host" as a definite 'thing' with its own identity that they might want to have.

Christ, I don't know any more, now I don't even know if I want to go back to calling it a subflavor (i.e. thinking of it as 'this is an image which contains an Atomic host' rather than 'this is an image which uses the Atomic/OSTree deployment method'). Grr....

Maybe I want 'ostree' as a deployment method and Atomic as a sub-flavor? Goddamnit, people, stop messing with my conceptual universe.

Matthew Miller wrote on 2015-09-18 16:43:
To throw even more in there, Fedora Atomic isn't just a Fedora spin which happens to contain the ostree tools and functionality. It's a a specific ostree, with package set and configuration chosen for that one specific (but hopefully broadly applicable) use case.
Colin Walters wrote on 2015-09-18 17:30:
Also, the partitioning defaults come with a split between OS and a "direct LVM" thin pool designed for Docker.