Atomic workstation

[Josh Boyer]

On Wed, Dec 3, 2014 at 3:29 PM, Colin Walters <walters at 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-docker-host.json
>
> 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