On Thu, Mar 06, 2014 at 11:30:29AM +0000, Colin Walters wrote:
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.
This model is appealing for some situations. I know we have people using
Fedora in production as desktop environments where that would be great. And
I think it will eventually be pretty useful for servers, although without a
good layer on top, we would just be, to extend your analogy, forcing
everyone to buy their groceries from a restaurant, and making them build and
run the restaurant if they don't have one already.
The Docker case is a good starting point because it is single purpose.
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).
Right now, it's not just any typical American restaurant. It's more like a
restuarants with a prix fixe menu, where your soup, salad, appetizer, main
dish, dessert, and beverage are all preselected together. Is that fair?
>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.
The important thing isn't Anaconda. It's that we can do it in Koji. Making
this be an ImageFactory plugin makes it easy to add to the upcoming Koji
release which has ImageFactory integration.
(Or, if Anaconda can just do it, that lets us use the ImageFactory stuff
which is already in the works.)
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>