Merge lp:~jtv/launchpad/db-bug-786970 into lp:launchpad/db-devel
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | no longer in the source branch. |
Merged at revision: | 10617 |
Proposed branch: | lp:~jtv/launchpad/db-bug-786970 |
Merge into: | lp:launchpad/db-devel |
Diff against target: |
559 lines (+211/-115) 10 files modified
database/schema/security.cfg (+6/-0) lib/lp/registry/browser/distroseries.py (+8/-11) lib/lp/registry/browser/tests/test_distroseries.py (+7/-3) lib/lp/registry/interfaces/distroseriesdifference.py (+0/-12) lib/lp/registry/model/distroseriesdifference.py (+0/-11) lib/lp/registry/tests/test_distroseriesdifference.py (+0/-18) lib/lp/soyuz/browser/archive.py (+3/-16) lib/lp/soyuz/browser/tests/test_package_copying_mixin.py (+0/-25) lib/lp/soyuz/model/packagecopyjob.py (+62/-0) lib/lp/soyuz/tests/test_packagecopyjob.py (+125/-19) |
To merge this branch: | bzr merge lp:~jtv/launchpad/db-bug-786970 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Gavin Panella (community) | Approve | ||
Review via email: mp+62292@code.launchpad.net |
Commit message
[r=allenap][bug=786970,787462] Register CannotCopy failures as DSDComments.
Description of the change
= Summary =
When a PlainPackageCopyJob fails with a CannotCopy error, that's not really meant to be an oops. It's meant to be an error that the user should address. But how do we tell the user? This job is something you "see going on" in the UI, so we want the errors in the UI as well — email is not an answer.
== Proposed fix ==
Julian and I (with feedback from Colin) decided on the following error-reporting mechanism: any one of the PlainPackageCop
Next we'll make the page poll, so that these messages can show up on the fly.
== Pre-implementation notes ==
Multiple package copies for multiple DistroSeriesDif
But alas. There are complications: it takes some relatively complicated tracking, and because the checks are to some extent phased, you might see your package failing because some other package broke the whole job. In the end we decided on a simple fix: only handle one package per job. This affects two callsites.
Another question is: what Launchpad user will the error messages be attributed to? An attempt to start a discussion about having a user identity to represent Launchpad in the database for this sort of thing failed miserably. We thought it might be easy impersonate the requesting user (which will be a little disconcerting because automatically generated messages meant primarily for the user will look as if they'd been entered by that same user). But the only current place for that information is Job.requester, which… isn't accessible in Python. In the end Julian gave me the green light to use the Janitor, which fulfills many of the roles that I had wanted a "Launchpad persona" user for.
== Implementation details ==
For once I remembered to test the new code for database privileges. Which revealed a few that were needed, hopefully saving us some agony later on.
Sadly gone are very similar bits of code that Gavin and I developed in parallel for collating packages by archive, so as to bundle them into the minimum number of PlainPackageCop
== Tests ==
{{{
./bin/test -vvc lp.soyuz.
}}}
== Demo and Q/A ==
Request asynchronous package copies on a derived distroseries' +localpackagediffs page. (Do this by requesting more copies than the max_synchronous
= Launchpad lint =
No lint, but it's complicated. I touched a file that had pre-existing lint, which I did not fix, and then I undid my changes to that file.
This looks really good.
However, I have a major beef with it: PlainPackageCopyJob is no longer geCopyJob, that
a plain copy job; it's now heavily intertwined with derivative
distributions. I think PlainPackageCopyJob should be restored, and a
new subclass created, something like DerivativePacka
knows about DSDs and so forth. It's unfortunate that that involves a
lot of boilerplate code.
Other than that, I think it's a shame that packages can only be copied
one at a time, but I can see this is a far from trivial problem to
solve. It does mean that there's no longer an all-or-nothing guarantee
when copying multiple packages. A *big* downside is that users must
check all DSD comments for errors when they request multiple copies. I
assume both of those are acceptable compromises for now.
[1]
+ try: ure(e)
+ self.attemptCopy()
+ except CannotCopy, e:
+ self.abort()
+ self.reportFail
+ self.commit()
Fwiw, the job runner commits after run(), so only the abort() is
needed.
[2]
+ def findMatchingDSD s(self) : archive. distribution series. distribution == source_distro]
[...]
+ source_distro = self.source_
+ return [
+ dsd
+ for dsd in candidates
+ if dsd.parent_
Can you do with with IDs instead?
return [
dsd
for dsd in candidates
if dsd.parent_
[3]
+ def test_findMatchi ngDSDs_ matches_ all_DSDs_ for_job( self): makeDistroSerie sDifference( ) roxy(self. makeJob( dsd))
+ # findMatchingDSDs finds matching DSDs for any of the packages
+ # in the job.
+ dsd = self.factory.
+ job = removeSecurityP
This should be naked_job.
Also in test_findMatchi ngDSDs_ ignores_ other_source_ series.