Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

James Slagle jslagle at redhat.com
Wed Mar 12 16:33:29 UTC 2014

On Tue, Mar 11, 2014 at 11:48:52PM +0000, Colin Walters wrote:
>    On Tue, Mar 11, 2014 at 5:17 PM, James Slagle <jslagle at redhat.com> wrote:
>      How is it incompatible with packaging? The read only root support that
>      already exists in Fedora today is what would be used.
>    In that /etc and /var are read-only.  Now you're right, there is read-only
>    root which makes sense for certain cases, but changing the OS content to
>    write to a special data partition is taking one farther away from the
>    generality of the package/FHS model.

The paths that we need to be writable under /etc, /var, or whatever would still
be writeable due to the bind mounting implementation of the read only root
support that is in Fedora. 

Perhaps that is a violation of the FHS on technical grounds.

But, to be clear, someone* saying the TripleO approach is "incompatible with
packaging" is equivalent to saying Fedora's builtin readonly root support is
"incompatible with packaging". And further, the exact same implementation of
read only root that will be in RHEL 7 will be "incompatible with packaging".

*not implying this is what you said, as i'm not sure what you meant

>      How do the images get built? Can you use existing image building tools,
>      or it something ostree specific?
>    The trees (not images) get composed using rpm-ostree.  It's just a wrapper
>    around yum --installroot + ostree commit.

Is there any similar equivalent for dpkg, like a dpkg-ostree? Just trying to
think about how an ostree solution could get as much adoption as possible.

My personal opinion is that TripleO, and OpenStack in general, should offer
differing implementations where it makes sense. Things like the Nova driver
model, storage backends, etc. I'd like to see TripleO offer such choices as
well where it makes sense.

>    From there after Anaconda support lands, one can install a tree (just like
>    a set of packages) into a disk image or bare metal.  In this model,
>    Anaconda will be doing far less - it'll just be copying data, not
>    depsolving or running through the SELinux labeling, etc.

FWIW, I definitely "see the light" so to speak with what ostree has to offer.
I've been hovering aound different package management solutions for quite a
while. Besides rpm, I spent a few years working closely with Conary, which you
mention on your RelatedProjects wiki. Even though I have a limited
understanding of the ostree implementation, it appears to hit the mark of what
I see as a very compelling update model.

-- James Slagle

More information about the cloud mailing list