On Thu, Mar 6, 2014 at 1:39 AM, Sandro red Mathys
<red(a)fedoraproject.org> wrote:
I agree it's a nice model but wouldn't set N to a very high value.
Right, I agree with that. In the same way that going to a restaurant
with 500 menu items is overwhelming.
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.
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.
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 :)
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.
> - The atomic model has some flexibility issues, and really
> assumes
> another container layer on top for actually using it for
> anything,
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.
Then they can replicate out their content from there.
A good example of this use case is the "coporate standard build" laptop
deployment, where the user has no ability to add/remove stuff.
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).
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.
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? :)
=)
One last question: even with ostree, we'd still create the image
using
ImageFactory/Anaconda, right?
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:
https://github.com/cgwalters/rpm-ostree/blob/master/src/autobuilder/js/li...
Right now, Anaconda has no idea about OSTree. But this is a very high
priority for me.