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:
Right now, Anaconda has no idea about OSTree. But this is a very high priority for me.
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
