FAD Goals and deliverables

[Paul W. Frields]

On Thu, May 14, 2015 at 06:03:17PM -0600, Luke Macken wrote:
> On Thu, May 14, 2015 at 04:44:29PM -0500, Dennis Gilmore wrote:
> > On Thursday, May 14, 2015 01:10:59 PM Luke Macken wrote:
> > > On Thu, May 14, 2015 at 08:31:55PM +0200, Kalev Lember wrote:
> > > > On 05/14/2015 07:45 PM, Luke Macken wrote:
> > > > > With regard to updates, I am in favor of getting bits out asynchronously
> > > > > as fast as possible. This means repos would hit first, then the various
> > > > > installers/trees/images trickle out shortly after as soon as they
> > > > > complete.
> > > > 
> > > > Would it be possible to have drpms go out asynchronously as well, so
> > > > that regular rpms hit the repos first and then drpms get synced out
> > > > later when they are ready?
> > > > 
> > > > Could be a nice speed improvement for the composes.
> > > 
> > > This would be great. I think it requires either decoupling the delta
> > > generation from mash, or being able to run a second pass with it that
> > > did deltas only. It might be possible with the current code, I'm not
> > > quite sure.
> > > 
> > > RPM deltas, OSTree deltas... we may want to think about making "delta
> > > generation" be it's own part of the process entirely.
> > with the current code and way it works it is really not possible to decouple. 
> > and its the opposite of what I want to do. The pieces need to be tightly 
> > integrated and cohesive. in order to get things out promptly we need to be 
> > able to distribute the load to produce all the pieces that are part of an 
> > updates push. make all the repos at once.  but do 6 repos on 6 boxes. not 6 
> > repos on one box in serial.
> 
> The latest bodhi masher code will mash all tags in parallel (after all
> security updates are done), and spreading this across multiple machines
> will most likely not help since they're all going to be fighting over
> /mnt/koji.
> 
> > fire off all the things needing those repos after 
> > they are done in one shot. release them all at once.  If we decouple the 
> > delivery I fear it will cause confusion for users. especially in the instance 
> > of something like heartbleed or shellshock when we say update now, but only 
> > some updates are out there.
> 
> So you're saying we should block critical security updates until all
> installers, images, etc are rebuilt for all releases? I think users are
> already confused as to why they don't get their security updates faster
> as it is, and preventing users from patching live systems because of
> various other components sounds dangerous.
> 
> I think a distinction needs to be made between updates and releases. We
> *update* existing repos/ostrees. We *release* new images/installers. We
> are trying to define a process to release new updated images/installers
> regularly, but jamming a "bi-weekly release" process into the current
> "as fast as we can keep up" package update process seems very awkward.
> 
> Now, if you think Bodhi2 should be the be one-stop-shop for composing, testing,
> gating, and pushing out all products with a single "sign, compose, and
> release everything at once" tool -- then that's fine too, we just need
> to start planning and prioritizing accordingly.

Also it's important we understand what "tightly integrated" means to
our ability to deploy fixes.  To what extent is that bound up with
e.g. an upstream Koji release?  (Is that an issue at all?)

The *idea* of more pluggable bits -- even in the context of Koji 1.x
-- suggests to me it's easier for Fedora to deploy improvements.  But
again, I'm looking for more information on how relevant that is.

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