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