Fedora Atomic and Docker Host Image [was Re: Docker Host Image: Requirements?]

Colin Walters walters at verbum.org
Thu Mar 6 11:30:29 UTC 2014


On Thu, Mar 6, 2014 at 1:39 AM, Sandro red Mathys 
<red at 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/libqa.js#L119

Right now, Anaconda has no idea about OSTree.  But this is a very high 
priority for me.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20140306/eae31571/attachment.html>


More information about the cloud mailing list