Merge lp://staging/~jtv/launchpad/db-bug-766807 into lp://staging/launchpad/db-devel
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Jeroen T. Vermeulen | ||||
Approved revision: | no longer in the source branch. | ||||
Merged at revision: | 10493 | ||||
Proposed branch: | lp://staging/~jtv/launchpad/db-bug-766807 | ||||
Merge into: | lp://staging/launchpad/db-devel | ||||
Diff against target: |
842 lines (+613/-28) (has conflicts) 11 files modified
database/schema/security.cfg (+4/-0) lib/canonical/config/schema-lazr.conf (+10/-0) lib/lp/archivepublisher/interfaces/createdistroseriesindexesjob.py (+26/-0) lib/lp/archivepublisher/model/createdistroseriesindexesjob.py (+155/-0) lib/lp/archivepublisher/tests/test_createdistroseriesindexesjob.py (+309/-0) lib/lp/archivepublisher/zcml/configure.zcml (+12/-2) lib/lp/services/job/runner.py (+39/-1) lib/lp/soyuz/interfaces/distributionjob.py (+7/-0) lib/lp/soyuz/scripts/initialise_distroseries.py (+13/-1) lib/lp/soyuz/scripts/publishdistro.py (+15/-23) lib/lp/soyuz/scripts/tests/test_initialise_distroseries.py (+23/-1) Text conflict in database/schema/security.cfg |
||||
To merge this branch: | bzr merge lp://staging/~jtv/launchpad/db-bug-766807 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Gavin Panella (community) | code | Approve | |
William Grant | code* | Approve | |
Graham Binns (community) | Abstain | ||
Review via email:
|
Commit message
[r=allenap,wgrant][bug=766807] Auto-create new distroseries indexes.
Description of the change
= Summary =
When a new distroseries is created (and we plan to publish it), several things need to happen. One of them is an initial run of the publish-distro script for the main and, if present, the partner archives. This is steps 12 & 14 in https:/
As part of our derivation work, we need to automate more of this process and generalize it beyond Ubuntu.
== Proposed fix ==
Use the job system. Set up a new DistributionJob
The job is created in the initialise-
For the Ubuntu case, the documented contacts are Lamont and Steve L. Steve is documented as the Ubuntu release manager, along with a very few others, so that makes this notification set a good fit to the existing process design.
We don't publish Debian releases, nor do we want to send notifications to its owners just because their releases show up in Launchpad. We have no publisher configuration in the database for Debian, which would break publish-distro. So in this branch I don't produce index-creation jobs for distributions that have no publisher config; I hope that is a compromise that will make everyone happy.
We may need either 1 or 2 publish-distro runs for a series. For the 2-run case, we could either generate a single job that performs both runs, or two separate jobs for the two respective runs. I opted for the former: humans are waiting for the news that this job is completed. Tracking successful completion of both gets much harder with two independent jobs.
== Pre-implementation notes ==
Without Julian available, we have to make do as best we can. Some of the details and caveats were discussed with wgrant, SteveK, and lifeless. Points that spring to mind:
* As a matter of design, the publish_distro script should remain unaware of distroseries.
* There's no particular reason to run publish-distro after creating the symlinks in the Ubuntu release process.
* All pockets should be generated, though only for the new distroseries. By default publish_distro processes the entire distribution.
In future we'll clearly want to automate a lot more of the Ubuntu release process. For now, creating individual jobs for each step should still be manageable. In future we may be able to automate steps 5, 6, 9, 10, and 18 relatively easily.
== Implementation details ==
The new job type was originally called InitializeDistr
You'll notice that I removed try_and_commit from the publisher code. This was a holdover from obsolete memory micro-management practices, but with those gone it's been stripped down to the point of uselessness. Ditching it made the code a bit easier to read.
The new job runner will have to run on the server that hosts the Ubuntu archives.
== Tests ==
{{{
./bin/test -vvc lp.archivepubli
./bin/test -vvc lp.soyuz.
}}}
== Demo and Q/A ==
The creation of the new jobs is controlled by a feature flag: archivepublishe
To test this feature on dogfood or similar:
* Enable the feature flag.
* Create a new distro release based on an existing release.
* You may need to go through some of the steps in the Ubuntu release process.
* Run initialise-
* Check that a DistributionJob of type 4 has been created for the new release.
* Run the job runner: cronscripts/
* This should run publish_distro and generate indexes in the distribution's dists root.
= Launchpad lint =
I left a few bits of lint in place: some unused variables because I don't want to damage the artistic integrity of the tests(*), and a long line because I think another concurrent branch already fixes it in a way that would cause conflicts.
(*) Meaning that whoever wrote them may have introduced the variables for legibility or consistency and I don't want to mess with what I do not understand (unless it's actually fun).
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
./lib/lp/
261: local variable 'ps' is assigned to but never used
271: local variable 'ps' is assigned to but never used
285: local variable 'test2' is assigned to but never used
324: local variable 'test2' is assigned to but never used
./lib/lp/
208: E501 line too long (80 characters)
208: Line exceeds 78 characters.
Jeroen
Hi Jeroen,
I took another look at this as promised but I still don't trust myself to give it a proper review; I don't have the context to be able to understand it without a lot of hand-holding.
I think it would be a good idea for you to arrange for someone else on your squad to review this; they'll likely have the necessary context (and also won't have just returned from a two-week break).
Apologies for punting,
Graham