needs to be smarter

Bug #54009 reported by Stuart Bishop on 2006-07-25
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Stuart Bishop

Bug Description should be smarter and only change permissions when it needs to,
rather than its current method of resetting everything and rebuilding from
scratch. This would make it possible to run the script against a live
database in most cases

 affects /products/launchpad
 assignee stub
 status confirmed

Stuart Bishop <email address hidden>
Canonical Ltd.

Stuart Bishop (stub) on 2006-07-27
Changed in launchpad:
importance: Untriaged → Wishlist
Stuart Bishop (stub) wrote :

This causes an outage of the login servers during upgrades. revokes all permissions and then resets then per config. This creates a window where the login servers do not have permission to read the tables they need to.

Changed in launchpad-foundations:
assignee: Stuart Bishop (stub) → nobody
importance: Low → High
milestone: none → 3.1.11
Gary Poster (gary) on 2009-12-15
Changed in launchpad-foundations:
milestone: 3.1.11 → none
Tom Haddon (mthaddon) wrote :

This is a virtual necessity now, especially given the drive towards continuous rollout. It has bitten us most recently with

tags: added: canonical-losa-lp
Gary Poster (gary) on 2010-10-13
Changed in launchpad-foundations:
assignee: nobody → Stuart Bishop (stub)
Stuart Bishop (stub) on 2010-11-15
Changed in launchpad-foundations:
status: Triaged → In Progress
milestone: none → 10.12
tags: added: qa-needstesting
Changed in launchpad-foundations:
status: In Progress → Fix Committed
Tom Haddon (mthaddon) wrote :

Is this a new option, or something that just happens automatically? Just wondering how we can apply this/test.

Its a new option - we can test it on qastaging: make the automatic
deploys run the --norevoke version only, and at the monthly deploy run
the full version when we test the full database patch story.

Stuart Bishop (stub) wrote :

So to be clear:
 - Update code on database host
 - Run --no-revoke
 - Update code on the rest of the systems

By granting the new permissions and not revoking old permissions, we no longer have a window where database permissions do not patch permissions required by running code.

If we want, after the update we can run normal to revoke permissions that should no longer be needed, but I don't think this gains us anything and just makes it more likely to shoot ourselves in the foot.

Gary Poster (gary) wrote :

Thank you Stuart. Have you called the LOSAs' attention to this? Alternatively, can a LOSA ack Stuart's message?

Stuart Bishop (stub) on 2010-12-02
tags: added: qa-ok
removed: qa-needstesting
Curtis Hovey (sinzui) on 2010-12-08
Changed in launchpad-foundations:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers