while true; do sleep 1h; rpm-ostree compose tree...; done

[Paul W. Frields]

On Thu, Oct 09, 2014 at 04:50:06PM -0400, Matthew Miller wrote:
> On Thu, Oct 09, 2014 at 04:33:12PM -0400, Paul W. Frields wrote:
> > * How often updates should be issued?  Who can decide this?
> 
> Since this is nominally a Cloud WG product at this point, I think that group
> will claim the decision if no one else has any strong objections or other
> ideas. Updates should be produced whenever any Fedora packages are updated.
> Colin tells me that an update where no packages that are actually in the
> tree are affected is optimized as a noop, so effectively this can be run as
> part of the regular nightly push.
> 
> 
> > * Which releases are updated, i.e. does the ostree lifecycle differ
> >   from standard Fedora?  Does the Atomic team need to check in with
> >   FESCo about this?
> 
> Having a different lifecycle was suggested but dropped. This _would_ be a
> FESCo decision at this point, and we've said that we aren't ready for
> different lifecycles.
> 
> Plus, since the discussion was to aim for a shorter lifecycle, I think
> keeping them in sync with the rest is a benefit we can provide for users
> with minimal extra work. We can then watch the usuage patterns and perhaps
> move to a shorter cycle in the future.

Thanks for this information.  It didn't seem to me other than space
concerns why it would be significantly more work to keep images on the
same lifecycle initially.

> > * ...which leads to how much storage is going to be required.  We can
> >   get storage, this is an important project and that is not a
> >   blocker.  But we can't plan without any idea whatsoever of
> >   magnitude.  This has to come from the Atomic team AFAICT.
> 
> Yes. It looks like the current tree is fairly large. Larger than I would
> have expected, really.

Right.  If someone can figure out roughly (to an order of magnitude?)
what storage will be consumed, that would help.  Resources are not a
blocker here, but we may have to communicate that to the proper places
in Red Hat to *get* them.

> > * Was it already figured out how mirrors deal with this content?
> >   Please understand the last I heard about the project, there was an
> >   issue with the number of HTTP requests involved.  I expect the code
> >   has moved on significantly since then.  Is there still some issue
> >   for mirrors?
> 
> Yes, that's an issue.
> 
> Initial plan is to _not_ mirror the content. Colin has a proposal for
> "static deltas" which will mitigate the issue but at the cost of more space.
> <https://mail.gnome.org/archives/ostree-list/2013-July/msg00005.html>
> 
> When we have that in place, we'll need a discussion with the mirrors about
> whether we want to 
> 
>   a) expand the informal agreement of "~ 1TB" to maybe twice that(
>      especially given that we're at 1.4TB already)
>   b) mirror atomic as a separate tree so mirrors need to opt in

Would you agree this is a decision we should try to have made
significantly before we get to, I don't know, F22 Alpha?

> > I don't want to be overly aggressive, but it would be disappointing if
> > we can't get this off the ground timely simply because knowledge isn't
> > being shared and questions aren't being asked and answered directly
> > and candidly.  I'm not sure that's the case here, but in poking around
> > I hear people saying they don't have information.  That seems out of
> > place in my Fedora experience, so it puzzles me.
> 
> Ditto!

Sorry if the above seems like Chicken Little.  I feel some of David's
frustration from trying to assist, and at the same time understand the
significance of Atomic/ostree and want to avoid pushing it off to F22.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com