launchpad-dev team mailing list archive

[James Westby <james.westby@xxxxxxxxxxxxx>]

On Thu, 5 Aug 2010 15:30:09 +0100, Julian Edwards <julian.edwards@xxxxxxxxxxxxx> wrote:
> On Thursday 05 August 2010 15:06:35 James Westby wrote:
> > On Thu, 5 Aug 2010 11:33:40 +0100, Julian Edwards 
> <julian.edwards@xxxxxxxxxxxxx> wrote:
> > > On Wednesday 04 August 2010 21:16:33 James Westby wrote:
> > > >    #        bugpackageinfestation -> SPR ???
> > > 
> > > Only main archives have bugs so it should not matter for COPY/PPA
> > > archives.
> > > 
> > > Deryck will have to fix this whenever they do PPA bugs :)
> > 
> > Well, I am adding code to delete PRIMARY archives, so I have to consider
> > what to do.
> 
> Why's that?  It's out of scope I thought - aren't you just deleting COPY/PPA 
> archives?

Then I misunderstood this:

   > On Tuesday 03 August 2010 13:34:30 James Westby wrote:
   > > Just to be clear, you are advocating deleting every trace of an archive
   > > (except records referenced elsewhere), as soon as the publisher runs
   > > after you delete an archive, for all archive types?

   > For all archive types where we support deletion, yes.  This is the only way 
   > that people can re-use the same name for PPAs after they delete them, unless 
   > they resurrect the same PPA again and are aware of its upload
   > history.

where in messages earlier in the thread you hadn't corrected me when I
said that PARTNER/PRIMARY/DEBUG were all deleteable.

> > Should the user be told on +delete that they can't delete as they have
> > outstanding builds?  I think that would be bad, as they won't care,
> > though we could warn them, as they may not know.
> > 
> > I think it would be better for the publisher to leave archives that are
> > DELETING in that state if they have outstanding builds and come back to
> > them next time.
> 
> Possibly, although I'm worried that will slow down the publisher with the 
> extra work.

Archive deletion will be fairly infrequent, such that there will only be
a few archive deletion requests at most outstanding at any one time. For
each there will be a query as to whether it has any builds outstanding?
Is that query going to take a long time?

> > Other references that I missed before:
> > 
> >   * packagecopyrequest - already CASCADE
> 
> I guess we need to check to see if there's a job active for the PCR, and 
> either kill it or prevent deletion.

Well, I'd just like to kill packagecopyrequest, but I'm hesitant to make
this work depend on that.

As for that particular case, there is a race between +delete and the
publisher running. Therefore we make the publisher skip and try again
next time, and have +delete remove any packagecopyrequest to prevent any
starting in the meantime, to reduce the load.

I'm not sure how we would kill a running job?

> >   * archivejob - should CASCADE?
> 
> Yes.

This is basically the same issue?

Aaron, what happens on Branch.delete() with BranchJobs?


Thanks,

James