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:
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
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.