Identifying Fedora media redux: What is Atomic?

You may remember my post from yesterday, on whether a 'Fedora Atomic' flavor made sense, and how I think about identifying Fedora media for my fedfind project.

Well, after talking it over with a few folks this morning and thinking some more, I've come to the conclusion that post was kind of wrong, on the major question: what is Atomic?

In that last post I came to the conclusion that Atomic was a deployment method. I still think deployment method is a perfectly viable concept, but I no longer think Atomic really is one. Rather, ostree is a deployment method, and Atomic really is - as I previously was considering it - something more like a payload.

Reading the Project Atomic site, it seems I was kind of working from an outdated understanding of the 'Atomic' concept. I'd always understood it as being more or less a branding of ostree, i.e. an 'Atomic' system was just one that used the ostree deployment method. But it seems the concept has now been somewhat changed upstream. To quote the Introduction to Project Atomic:

"The core of Project Atomic is the Project Atomic Host. This is a lightweight operating system that has been assembled out of upstream RPM content. ...

Project Atomic builds on these features, using the following components, which have been tailored for containerized-application management:

• Docker, an open source project for creating lightweight, portable, self-sufficient application containers.
• Kubernetes, an open source project that allows you to manage a cluster of Linux containers as a single system.
• rpm-ostree, an open source tool for managing bootable, immutable, versioned filesystem trees from upstream RPM content.
• systemd, an open source system and service manager for Linux."

There is still some conceptual confusion about exactly what Atomic means - for instance, there's a concept called Atomic Apps, and it is apparently fine to deploy Atomic Apps on systems which are not Atomic Hosts. But after discussing it with some folks this morning, I think it's reasonable to take the following as a principle:

Any Fedora image with 'Atomic' in its name deploys as an Atomic Host as defined by Project Atomic.

Assuming that rule holds, for 'image identification' purposes under the fedfind concepts covered in the previous post, atomic really does work best as something in the line of a flavor, loadout and/or payload. It also implies the deployment method ostree, but I think I'm OK with leaving that concept out of fedfind for now as it's functionally useless: as all Atomic images have ostree deployment and all non-Atomic images have rpm deployment, distinguishing the properties is no use at this point. I'm going to hold it in reserve for the future, in case we get other images that use non-RPM deployment methods but are not Atomic hosts.

For now I think I'll more or less go back to the subflavor concept I initially threw out in favour of deployment, and for current purposes, all Atomic images will have flavor cloud and subflavor atomic. The alternative is to have a concept that's a bit more parallel to flavor and loadout which feeds into payload, but for now keeping the interface stable seems better.