On Tue, 07 Jun 2011 16:17:27 -0000, Paul Sokolovsky <email address hidden> wrote:
> On Mon, 06 Jun 2011 18:55:30 -0000
> James Westby <email address hidden> wrote:
> > That sounds like a useful part of a solution to me, provided that the
> > sync is atomic and so a failed sync on the soft_delay period doesn't
> > corrupt the repos.
> 
> Can you elaborate on this? If by corrupt you mean inconsistent state,
> then it may be not that bright - git pull is of course atomic, but repo
> just pulls git subtrees one by one, so it can be the case that one
> subtree is updated, while another not.

If we are doing soft_delay syncs that fail and corrupt the repo such
that no-one can do a build then there's no practical difference with
this approach to the one-timeout approach. Either way if the upstream is
down then no-one can do a build anymore.

I think this means it just needs to be atomic at the git repo level,
though there will be an odd occaision where skew would cause a build
failure that wouldn't have been there had the partial sync not happened.

That's not a big problem though, and so given that git is atomic this
should be fine.

> Well, it's matter of concept separation. So far, what's in the build
> config, affects just that build. Mirror control, on the other hand, is
> on another level, and may affect other builds.
> 
> Usecase:
> 
> 1. Mirror has synced, and upstream host soon went down.
> 2. During soft_stale period, all builds would still succeed.
> 3. But one developer decided to force mirror sync (essentially
> by removing last sync timestamps).
> 4. As upstream host is down, the sync didn't succeed.
> 5. Developer's build thus failed.
> 6. But any other build since this build will also fail. (Whereas
> otherwise there would soft_stale fail-free period).

Why would other builds have to fail?

> Taking into account that build config changes are persistent (vs
> one-off), I envisioned "force sync" feature as a separate, special
> frontend action available only to build admins (like ability to create
> official builds). But if you think that controlling it on the build
> config level is useful and scenario above isn't problematic, it can be
> done there.

My argument wasn't so much about where we put it, but the user
experience. If it is it's own action, then I have to babysit it as it
syncs until I can start my build.

If however I say "build now and ensure that the mirror is up to date"
then I can go away and either get the build I want, or get a failure if
the mirror is not up to date.

> And we still can start with just providing couple of scripts on
> android-build.linaro.org, so people with access can SSH in and do:
> 
> force-mirror-sync - next mirror service request will force mirrored
> repos update (impl: remove last sync timestamps for all hosts)
> 
> pretend-mirror-sync - mark all hosts as if they were just synced, the
> remedy for prolonged upstream host unavailability (impl: touch last
> sync timestamps)

Sure, these may be useful things to have, but I don't think they address
the use case I am discussing.

   As an Android build service user I want to trigger a build
   immediately after seeing a fix I need committed to an upstream repo
   and be sure that my build will see that fix so that I can react
   quickly to upstream changes

Thanks,

James