launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Thursday 05 August 2010 16:12:12 James Westby wrote:
> On Thu, 5 Aug 2010 15:30:09 +0100, Julian Edwards 
<julian.edwards@xxxxxxxxxxxxx> wrote:
> > 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.

Oh, my apologies if I've mislead you on that then, it wasn't intentional.

It's possible that we might want to delete them in the future of course (when 
we have loads of derivations).

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

I would hope not, but I get a bit paranoid about publisher performance :)

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

It seems odd that someone would initiate one of these and then immediately 
want to delete the archive.  It's most likely to be a mistaken deletion 
surely?  In which case it would make more sense to refuse the deletion.  If it 
becomes a problem later then we can do the extra work to kill the Job, but I'd 
cover the simple cases first to reduce the work here.

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

Me neither, which is why I think we should avoid it for now as above.

Cheers.