[CentOS-devel] ostree as a delivery model

[Jim Perrin]

On 04/17/2014 12:51 PM, Colin Walters wrote:
> On Wed, Apr 16, 2014 at 10:39 PM, Mike Schmidt 
> <mike.schmidt at intello.com> wrote:
>> I read about that too, today. Is there any thought of a Centos atomic 
>> spin? Is this an open source effort by redhat?
> 
> Of course!


We'll very likely be working on this in the immediate future. It relies
on the 7 code base, so it will likely be proof-of-concept/demo for a
bit. Once we have some time to discuss it as a project we'll see what we
can put together.


>> Or maybe a spin more like CoreOS (https://coreos.com) which looks 
>> like a different (simplified) take on the same general idea? Both 
>> atomic and CoreOS are even more than minimal images since they are 
>> built to do nothing else but run docker containers. I' m going to 
>> give CoreOS a try to see how it's put together; there seem to be a 
>> few good ideas there. 
> 
> It's clear the CoreOS team has some great ideas and has put a lot of 
> thought into a new model for OS+app delivery.
> 
> But what I'd say on this is that I'd like Project Atomic to closely 
> orbit the RPM ecosystem.  For example, realistically you need content 
> that goes into base images that gets reliable security updates.  The 
> OpenSSL scenario shows the danger of just pulling arbitrary application 
> content.

To me, this is one of the easy wins. CoreOS is a separate code base.
With Atomic, you keep the OS familiarity with tools and packages, and
generate images via kickstart just like a normal deployment. This way
it's not as drastic a workflow shift and for the most part, it helps
keep things consistent, and you can track package updates the same way.

> The traditional package model has been able to deliver security 
> updates, and we need to be careful not to throw that away - while still 
> allowing people to have the option to run complete app images from the 
> upstream app author directly and rely on them for security updates.
> 
> Furthermore of course on the host OS side, with rpm-ostree, you're 
> taking *only* known RPM content into the host OS.  While it's true that 
> like Docker, the OSTree delivery vehicle is content-agnostic, you might 
> note from the very name of rpm-ostree that the tool will closely bind 
> together the RPM world of individual packages and the OSTree world of 
> trees.  I have some pretty exciting hybrid package/tree functionality 
> on the roadmap, so stay tuned there =)

Nice teaser. Now we're going to want more details. :-P



-- 
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77