On Wed, Dec 3, 2014 at 3:29 PM, Colin Walters <walters(a)verbum.org> wrote:
On Wed, Dec 3, 2014, at 02:22 PM, Matthias Clasen wrote:
> Hi Colin,
>
> I wondered what your thoughts are about the possibility of serving the
> workstation image as a tree in Fedora atomic.
The TL;DR on this is that rpm-ostree would be extremely disruptive. I believe the
technology is worth the benefit of that pain, but realistically until its feature set
enhances, I suspect most users would want to stick with traditional package manager
tradeoffs.
Longer answer:
Currently rpm-ostree is focused on use in the Project Atomic context, when paired with
Docker/Kubernetes.
However, before that happened, this was an initial goal of the rpm-ostree project, and
you see that reflected in the branch names:
fedora-atomic/rawhide/x86_64/docker-host
Where the last bit of "docker-host" is a *name* for a set of packages, here:
https://git.fedorahosted.org/cgit/fedora-atomic.git/tree/fedora-atomic-do...
It's quite easy in fact to make a workstation tree, that would appear as
fedora-atomic/rawhide/x86_64/workstation
> It would be interesting for the atomic update and rollback capabilities
> that ostree offers.
Right, but for the Workstation use case this runs quickly up against the
fact that the tree is immutable locally. See
https://github.com/cgwalters/atomic-pkglayer
for some prototype work there.
Out of curiosity, couldn't you have an atomic/ostree "base" layer that
is immutable (perhaps shared between Base, Server, Cloud,
Workstation), and then use Docker containers on top of that as the
"live" system? That would still fit with the "atomic is for Docker"
approach you have today, while also giving some flexibility at the
application layer. One could imagine Software installations become
"create a new Docker container with this app inside of it", which then
leads to it be automatically sandboxed, etc.
Still, switching out the underlying atomic layer and having the upper
level Docker containers still work fine might be challenging. The
point is to create more of a stackable approach to the Products,
rather than trying to make the entire Product an atomic image.
josh