On Thu, Mar 6, 2014 at 1:39 AM, Sandro red Mathys <red@fedoraproject.org> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">
I agree it's a nice model but wouldn't set N to a very high value.</div></blockquote><div><br></div><div>Right, I agree with that. In the same way that going to a restaurant with 500 menu items is overwhelming. </div><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">Also, I worry a bit about the QA and tracking down bugs (most devs
will always point at ostree). But happy to explore the possibility.</div></blockquote><div><br></div><div>Remember that "rpm -qa" works - a tree is always composed of a set of packages. So you can determine what versions of packages you have, file bugs against them, etc. OSTree is just pre-computing on the build server what in the traditional package world happens per-client.</div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">Oh, totally. Still, I would rather have a statement from Colin Walters
that states it's in a good enough state for our use case. Leading-edge
is good, broken edges aren't :)</div></blockquote><div><br></div><div>Short answer: Yes, I think so. Longer answer: It varies a bit. Most of the core design has been implemented for ~1.5 years, and I and others have done many upgrades using it. The rpm-ostree layer being in a functional state is much newer, and things like the SELinux integration are quite new.</div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"><blockquote> - The atomic model has some flexibility issues, and really assumes
another container layer on top for actually using it for anything,</blockquote></div></blockquote><div><br></div><div>I would agree with this - except that a model I think many people will like is using the rpm-ostree tool to spin their own *internal* OSTree repositories from the Fedora package set plus their custom stuff.</div><div><br></div><div>Then they can replicate out their content from there.</div><div><br></div><div>A good example of this use case is the "coporate standard build" laptop deployment, where the user has no ability to add/remove stuff.</div><div><br></div><div>In my food analogy, traditional RPM delivery is like a grocery store, and OSTree is more like a restaurant (attached to the grocery store, using its ingredients).</div><div><br></div><div>This model then is like a corporate cafeteria that buys ingredients from the upstream grocery store, and creates their own food, likely reusing recipies from the restaurant, and adding their own ingredients.</div><div><br></div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">Which we do, and that technology is called Fedora! ;) But sure, why
not do Fedora < ostree < Docker. Can't hurt to staple the
blood-smeared edges, right? :)</div></blockquote><div><br></div><div>=)</div><br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">One last question: even with ostree, we'd still create the image using
ImageFactory/Anaconda, right?</div></blockquote><br><div>So rpm-ostree also contains code to make .qcow disks. It's not as flexible as Anaconda, e.g. the partition layout, bootloader, etc. is hardcoded:</div><div><br></div><div><a href="https://github.com/cgwalters/rpm-ostree/blob/master/src/autobuilder/js/libqa.js#L119">https://github.com/cgwalters/rpm-ostree/blob/master/src/autobuilder/js/libqa.js#L119</a></div><div><br></div><div>Right now, Anaconda has no idea about OSTree. But this is a very high priority for me.</div><div><br></div><div><br></div>