launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

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?

> > >    # archivepermission -> Archive <- DELETE
> > >    # archivesubscriber -> Archive <- DELETE
> > >    # build -> Archive, SPR
> > >    #    buildqueue -> build
> > 
> > We can't delete the archive if it has outstanding builds.  That makes
> > things much easier, so we can ignore BuildQueue, Job and friends.  We
> > also have a bug where a builder becomes stuck if we delete its running
> > job from LP.
> > 
> > The buildfarmjob and packagebuild should also be removed.
> 
> 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.

> 
> > > We won't delete those builds, so
> > > we either have to remove the NOT NULL on the build->archive reference,
> > > or keep the Archive around. Either way we need to test what happens if
> > > you go to a build page where the build references a deleted archive.
> > 
> > If someone has copied with binaries we have to break this link and make
> > the code deal with the NULL.  I can't even remember why archive is
> > needed on that table.
> 
> You added CASCADE to build->archive and BPR->build. This means that we
> have all or nothing on archive deletion, not reference counting. We have
> to undo at least one of those, would you rather have BPR->build
> NULLable, or build->archive NULLable?

Argh.  That sounds like I was wrong doing that then.  There must always be a 
build for a BPR, so build.archive should be nullable.

> There is also SourcePackageRecipeBuild that I missed before. This is
> CASCADE on Archive, but there are several references to it that need to
> be taken care of.
> 
>   - SourcePackageRecipeBuildUpload - CASCADE?
>   - SPR - already NULLable, so again it's just that we could have an
>        SPR that we don't know the origin of any more.
>   - SourcePackageRecipeBuildJob - prevent deletion?
>   - SourcePackageRecipeData - CASCADE

I'm not as familiar with that data model.  Aaron?

> > > archivedependency is a little tricky as it has two FKs to archive.
> > > Where the dependency is specifying what the archive being deleted
> > > depends on it should be deleted, but what about where the archive is
> > > depended on by another? Given that we are removing all the packages
> > > anyway, I think it makes sense to delete them too, but it may lead to
> > > some surprising behaviour for people.
> > 
> > Indeed, we need to generate warnings at least for the deleter, but
> > preferably also on the PPA page that was depending on the deleted
> > archive.
> 
> It sounds like an awful lot of work to put a message on the PPA page for
> the archive that depends on the other.

Yep, that's why I said "preferably" :)  I know it's going to be hard.

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

>   * archivejob - should CASCADE?

Yes.

>   * SourcePackageRecipe.daily_build_archive - already NULLable. Again a
>      warning here would be appropriate when deleting.

Aaron would have to comment there.

> 
> Actions:
> 
>   * Add CASCADE for anything that it is appropriate for that doesn't
> already have it.
>   * Add a warning on +delete about archives that depend on this one,
>     outstanding builds and recipes that daily build to this archive.
>   * Have the publisher check for outstanding builds and skip the archive
>   * Make Archive NULLABLE on the tables where it isn't CASCADE.
>   * Test codepaths that use .archive on these objects to check they can
>     handle None.
>   * Delete the signing key if it is the last archive referencing it.

Can you see why we didn't do this already? :)

Thanks for getting stuck in.

J.