Merge lp:~linaro-infrastructure/launchpad/workitems-migration-script into lp:launchpad
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Steve Kowalik on 2012-03-01 | ||||
| Approved revision: | no longer in the source branch. | ||||
| Merged at revision: | 14893 | ||||
| Proposed branch: | lp:~linaro-infrastructure/launchpad/workitems-migration-script | ||||
| Merge into: | lp:launchpad | ||||
| Diff against target: |
710 lines (+573/-2) 7 files modified
database/schema/security.cfg (+5/-0) lib/lp/blueprints/tests/test_workitem_migration.py (+250/-0) lib/lp/blueprints/workitemmigration.py (+161/-0) lib/lp/scripts/garbo.py (+78/-1) lib/lp/scripts/tests/test_garbo.py (+71/-0) lib/lp/services/features/flags.py (+7/-0) lib/lp/testing/layers.py (+1/-1) |
||||
| To merge this branch: | bzr merge lp:~linaro-infrastructure/launchpad/workitems-migration-script | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Steve Kowalik (community) | code | 2012-02-20 | Approve on 2012-03-01 |
| j.c.sackett (community) | Approve on 2012-03-01 | ||
|
Review via email:
|
|||
Commit Message
[r=jcsackett,
Description of the Change
This is the script to migrate work items from the whiteboard to the new table. We're not going to run it until we have the new UI to edit work items separately from the whiteboard, though.
| Guilherme Salgado (salgado) wrote : | # |
On 22/02/12 00:48, Steve Kowalik wrote:
> Review: Needs Fixing code
>
> I'm going to mark this as Needs Fixing. This requires discussion, and certainly doesn't require a one-shot script -- the usual modus operandi for migrations like this is either a garbo job or an API script.
Can you let me know what is it that needs discussing? The
implementation, the migration itself or something else?
Also, the idea is to run this as a garbo script; I've implemented it
using a TunableLoop for that reason. IIUC we'd just need to add it to
the list of tasks executed by garbo, which I haven't done because the UI
hasn't landed yet.
From testing it against staging data, though, it seems to parse and
migrate ~90% of the whiteboards with work items, so my gut feeling is
that we won't need to run it for long.
| Steve Kowalik (stevenk) wrote : | # |
The implementation does. If the idea is to run it as a garbo job, then do that -- add it the loop in lib/lp/
| Guilherme Salgado (salgado) wrote : | # |
The separate script is just to make it easy to test this on staging. Also, we don't want to hook the new TunableLoop into garbo yet as we don't want it running on production until the UI has landed. And I've put it all in a separate file to make it easier to remove it after all whiteboards have been migrated. If you feel strong about it, I can move the code/tests together with the other garbo stuff, but can you please also review the code itself as shuffling things around shouldn't change much of the actual code?
| Steve Kowalik (stevenk) wrote : | # |
If you want to QA this on staging, and not have it running on production then add the loop to HourlyDatabaseG
* Your imports do not meet our standards. There are three groups: Standard Python modules, contributed code, then internal modules, all of which must be in alphabetical order.
* Some of your assertions look to add gratuitous vertical whitespace, why?
* I'd prefer more descriptive names rather than say 'nonono' for a IPerson that doesn't exist.
* + words = text.replace('(', ' ').replace(')', ' ').replace('[', ' ').replace(']', ' ').replace(
* SpecificationWo
* The script is not needed due to the above comment.
I was holding off on reviewing it until it moved into the garbo infrastructure, since it may change the code a fair bit.
| Steve Kowalik (stevenk) wrote : | # |
Another suggestion is to use a feature flag to guard this code. Then the garbo job will run on both production and staging, but will not do any work until the feature flag is turned on.
| Guilherme Salgado (salgado) wrote : | # |
On 28/02/12 19:25, Steve Kowalik wrote:
> If you want to QA this on staging, and not have it running on
> production then add the loop to
> HourlyDatabaseG
> removal point is moot, since we can just rollback the revision that
> included this garbo job. I do feel very strongly about this, and will
> not approve it as-is.
>
> * Your imports do not meet our standards. There are three groups:
> Standard Python modules, contributed code, then internal modules, all
Should be fixed now
> of which must be in alphabetical order. * Some of your assertions
> look to add gratuitous vertical whitespace, why? * I'd prefer more
Do you mean things like:
I've rearranged the arguments on those so that they fit in two lines.
If you mean something else, I'd appreciate if you could be more specific.
> descriptive names rather than say 'nonono' for a IPerson that doesn't
Changed
> exist. * + words = text.replace('(', ' ').replace(')', '
> ').replace('[', ' ').replace(']', ' ').replace(
> '').split() Really?! Surely this could be done better without having
> to chain six function calls together? *
It certainly could, but this code is known to correctly parse all
variants of work-item headers (it was taken from
launchpad-
this away once the migration is done, I'd rather not rewrite it to avoid
the regressions I might introduce when doing so. I know I could write
tests for all variants to ensure no regressions are introduced and I'd
be happy to do so if we were planning to keep this code around for some
reason, but that's not the case here.
> SpecificationWo
> is not needed due to the above comment.
Right, removed.
>
> I was holding off on reviewing it until it moved into the garbo
> infrastructure, since it may change the code a fair bit.
It didn't change much; I only had to move stuff around and write a test
using the test infrastructure for garbo, which is probably nicer than
running the script as a subprocess.
| Steve Kowalik (stevenk) wrote : | # |
So I think I'm going to change my mind, sorry. I am extremly happy with this as it stands, but you will have an easier time QAing and deploying this if you change the garbo job to only run if a certain feature flag is set. I'd suggest lp.scripts.
| Guilherme Salgado (salgado) wrote : | # |
Ok, I've added the feature flag and guarded the new garbo job with it.
| j.c.sackett (jcsackett) wrote : | # |
The feature flag stuff looks good to me. I'll be speaking with Steve in a few hours and if he's cool with everything we can send it off to land. I don't want to step on his toes and he clearly has a fuller understanding of how this fits into LP.
| Steve Kowalik (stevenk) wrote : | # |
Thank you for bearing with me through my review, I am happy for this to land.

I'm going to mark this as Needs Fixing. This requires discussion, and certainly doesn't require a one-shot script -- the usual modus operandi for migrations like this is either a garbo job or an API script.