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