Atomic status

[Stephen John Smoogen]

On 18 July 2014 07:40, Colin Walters <walters at verbum.org> wrote:

> Hi,
>
> I feel like things aren't moving forward quickly enough with Atomic,
> both on the Docker base image side and the rpm-ostree host side.  A lot
> of that is to be expected - we're trying to introduce *two* new ways to
> deliver software beyond RPMs at the same time.  It's quite nontrivial.
>
> There's also:
> 1) We're trying to do new projects, but we haven't added significant
> human resources
> 2) This is also the first Fedora.next release
> 3) We don't know how popular the whole Atomic/Docker model will be until
> we do a stable release really, but it's hard to get current
> Infrastructure people to spend time on it without knowing how valuable
> it is...
>
>
I don't want to go into 'if X is more valuable than Y' as even if
Atomic/Docker is the most valuable item we would still have 1 & 2 taking up
all our time.

1) is even worse because we are actually down several full time people
because Seth Vidal did the work of multiple people (from development,
systems architecture, and administration). There are also large pushes of
existing projects to grow. Matt Domsch who did 99.9% of the mirrormanager
work did this on his volunteer time which has had to be directed elsewhere.
This means that the code has to be updated and looked at by new people
which is taking time.

2) effectively adds 2 releases onto our one set which means that various
tools have to be rebuilt. Then add in several secondary architectures being
added.


Let's look at blocking issues for Atomic in Fedora:
>
> - Having rpm-ostree be run as part of nightly compose
> - Content mirroring
>   * Server with SSL, some level of redundancy
>   * Open question around how often/when composes are done, and how much
>   history is retained
> - GPG signing
> - Method of having Koji/ImageFactory pull mirrored OSTree repository
> content to compose ISOs
> - MirrorManager integration (no code written on ostree side yet)
>
>
Most of the above are also in grumpy areas of infrastructure where adding a
person to fix it means they will need to learn a lot of other things before
it works well or doesn't snag up something else. It would be good to add a
person, but don't expect an instant win but more instant pain in doing so.

There is also a part where infrastructure and releng are separate units in
some ways and not separate in others. Some of your blockers are on one and
some are on another and some in between. I can really answer on the content
mirroring side as I believe we can figure out a way to do that. Other parts
are on koji developers and other developers who work on signing.


-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20140718/6bda5275/attachment.html>