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@xxxxxxxxxx> 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 -- _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
