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

[Kevin Fenzi]

On Thu, 9 Oct 2014 16:50:06 -0400
Matthew Miller <mattdm at fedoraproject.org> 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.

Depends on what thing you mean. :) 

If added to rawhidecompose script: 1x/day. 
If added to the branched compose script: 1x/day (if we are in a freeze
and 0 packages have gone stable, per above I guess this is a noop)

For after release... not sure. We don't have any daily compose outside
bodhi. We would have to come up with a _Different_ script/process to do
these, either in bodhi or triggered by bodhi pushing updates. 

> > * 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.

Right. 
> 
> 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.

Yeah, it's too early to tell, sticking with Fedora until we know more
is a good idea, IMHO. 
> 
> > * ...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.

:( 

> > * 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

So, the nightly rawhide/branched composes _are_ mirrored. So, if we
add it to those scripts we would need to put it in another location if
we don't want it mirrored. 

> > 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!

I think part of the problem is that there's a ton going on, and atomic
is just so different from the rest of everything we don't know how to
deal with it. :( 

We will get there, I would urge patience and understanding... 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/rel-eng/attachments/20141009/d8d970bd/attachment.sig>