As with Container Linux, the best practice will be re-provisioning, due to the cloud-init/Ignition transition at least. Since Fedora CoreOS will be using rpm-ostree technology, it may be possible to rebase from Fedora Atomic Host to Fedora CoreOS. This will be part of a “migrating from Fedora Atomic Host” guide which will be published as soon as an actual version of Fedora CoreOS is available.
Since Fedora CoreOS (I think we should lose the OS, in the name. Fedore Core is an OS ) will be based on rpm-ostree the ostree utility will be there.
The question is, will the following two utilities be in Fedora Core as well?
- atomic ( even renamed, doesn’t matter ) or a tool to store container images in ostee and launch them with systemd and runc
Is there a pointer to the guide “migrating from Fedora Atomic Host”? Is this place forto give feedback/input?
Atomic CLI (also known as
/usr/bin/atomic) does a lot of different things. I definitely think parts of the functionality of Atomic CLI will be part of Fedora CoreOS, but we’ll probably re-evaluate parts of it as we go. For example Atomic CLI is a wrapper for a lot of different tools and we’re not convinced that’s better than using the individual tools themselves (for one it’s a pain to maintain).
skopeo (pulling/pushing/searching registries) is pretty fundamental so I don’t see that going anywhere. OS extensibility (system containers,
torcx, package layering) are very much open topics at this point. While it’s nice to be able to extend the OS it also makes it harder to guarantee automatic updates will be rock solid. We’ll have to consider the positives/negatives of these as we go.
The guide doesn’t exist yet (since we don’t actually have anything to migrate to). Once we have some artifacts we’ll start to formulate the guide
I really hope package layering do not go away. The toolbox container is solving problem like needing nmap, tcpdump, etc, but I think there need to be a way to run application when containers tooling is dead/not working, if only for debugging things. Or just vim, since /etc in the tool box would be different from outside, this kind of stuff.
For me, the major selling point for Fedora Atomic Host is that package layering to the host itself is possible. Without that, a large portion of the value for this goes away for me.
In the beginning, I was also grateful for package layering but to be honest if you need it then you should just use Server/Cloud edition. Using Container Linux in work also convinced me about that and confirmed that Atomic Host can function without layering. Altho’ what is important and is a big advantage over Container Linux is the ability to easily and quickly compose custom OSTree deployments.
Using custom OSTree to install 1 or 2 packages is more cumbersome than package layering. This requires work to keep the file in sync with upstream, you need to host the repository so that’s one 1 or 2 servers to take care of + HA setup for something solid. And you also need to take care of the build system, dealing with ressources, cpu, disk, etc.
And in the end, this doesn’t bring anything more to the user, since you would still have the same issues as package layering, except on a different system.
If the reason to remove package layering is “to have rock solid upgrade”, I am quite sure that custom ostree would also cause trouble for that, cause if we can’t have rock solid upgrade with packages added, I am quite sure that we can’t have it the whole image can be different.
If we look from another perspective, someone needing to install just 1 package (either bugfixes, test, or some debugging tools) would suddenly have to setup a whole system (aka, a custom build) for a one-off installation. And if something is broken in the image, but I need a whole setup to test a fix, chances that some people might just give up. So either give up the distro (so losing users), or just wait until someone else do the test, and/or test next version, so we lose velocity and have a longer feedback loop.
On top of that, no one really speak of the elephant in the room:
“who decide what go in the image”. And I am not even speaking of “should kubernetes be built-in or not”, that’s mundane stuff like support for nfs-client or not, etc. Package layering was a easy way out to avoid those kind of discussion, because suddenly, this is much less critical to be in the image. But removing the easy solution will automatically bring back those discussions
Why would you choose not to have fully transactional updates, an always read-only /usr, etc?
The “problem” is that my “one package” I’m adding is ZFS On Linux.
So the problem is maybe more regarding current dkms and ostree than package layering. I didn’t look yet, but I wonder how initrd modification (in my case for tang/clevis on silverblue) would work.
And maybe one solution that we speak of packages layering, but not all packages are equal on that matter. A single binary package wouldn’t cause much trouble, something affecting systemd would be different.
DKMS is completely unsupported in the current version of OSTree. I’ve talked about DKMS support with Colin Walters on DevConf.cz this year and he is aware that this is something that at some point have to happen if we want Nvidia drivers, for example, to work - both desktop and server (CUDA) require this closed source crap to work and they are distributed as DKMS modules.
In case of ZFS I’m building kmod RPMs for each kernel release, thankfully ZFS On Linux supports both DKMS and kmod packages. Basically preparing kmod version of modules delivered currently as DKMS is the only working solution for now.