launchpad-dev team mailing list archive

[William Grant <wgrant@xxxxxxxxxx>]

On Thu, 2010-05-06 at 18:08 +0200, Michael Nelson wrote:
> On Thu, May 6, 2010 at 5:34 PM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi all,
> ...
> > I bring this up because Soyuz is currently in the middle of redesigning
> > the build system, and this is therefore a good opportunity to bring more
> > similarity to our systems.  The Code Import system is also a candidate
> > for convergence, but the Code team isn't currently redesigning it.
> >
> > AIUI, part of the redesign of the build system involves creating a
> > Buildjob table with many fields that are similar to the Job table.  I
> > propose that the buildjob table should hold only fields that are not
> > generally relevant to jobs, plus a reference to the Job table.  This may
> > entail adjusting the Job table to better fit the build system's needs.
> 
> Hi Aaron,
> 
> I created the following a few weeks ago for that exact reason:
> https://bugs.launchpad.net/bugs/570939
> "Replace BPJ and SPRBJ with IBuildFarmJob.job"
> 
> The new IBuildFarmJob model will certainly have many fields similar to
> the Job table, and as we spoke on the phone the other day, I hope we
> can replace those fields simply with a reference to the job (as in the
> above bug).
> 
> But it isn't as straight-forward yet as simply switching the fields as
> the other temporary tables mentioned in the above bug reference the
> job already and are deleted (along with the job) after the queued
> build job is processed. The current refactoring is (IMO), a big step
> towards being able to do what you've suggested, but it's aim is to
> generalise the builds (which will always sit on top of services.Jobs),
> without touching the current queuing infrastructure which links to the
> job in strange ways (and deletes them afterwards).
> 
> That said, another intermediate option that might allow us to simply
> use something like IBuildFarmJob.services_job (and remove the relevant
> fields from IBuildFarmJob) without affecting the current queuing
> infrastructure might be to simply to ensure that when the current
> queue records are deleted after the build finishes that we just don't
> delete the job. Julian? William?

Why do we want an intermediate option? I don't imagine the refactoring
of the queue infrastructure is too far off, and we should be able to
losslessly migrate permanent data into a services Job later. I think
that introducing a separate permanent Job in between is just going to
unnecessarily complicate things.

Apart from that, I am all for unifying the two systems. I agree that it
would be much nicer if builds were really just a special class of jobs.