Duplicate tables for SSO service

Bug #489078 reported by Stuart Bishop
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Stuart Bishop

Bug Description

Currently, the login service is accessing Launchpad data directly. We want to break this dependency.

To do this, we need to create mirrors of the following tables kept up to date with PostgreSQL triggers or rules:

    person
    personlocation
    teamparticipation

These tables will not have any foreign key constraints, and will be added to a new Slony-I replication set. The login service database will be subscribed to this new replication set, making it available to the login service even when the Launchpad database is down for maintenance.

Related branches

Revision history for this message
Stuart Bishop (stub) wrote :

We want to land this cycle to ensure we keep to the login service timeline.

Changed in launchpad-foundations:
status: New → Triaged
importance: Undecided → High
assignee: nobody → Stuart Bishop (stub)
milestone: none → 3.1.11
Revision history for this message
Stuart Bishop (stub) wrote :

db patch done.

Need tests.

Need to update upgrade.py and friends to put the new tables in their own replication set.

Changed in launchpad-foundations:
status: Triaged → In Progress
Stuart Bishop (stub)
tags: added: current-rollout-blocker
Stuart Bishop (stub)
Changed in launchpad-foundations:
status: In Progress → Fix Committed
Changed in launchpad-foundations:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.