Duplicate tables for SSO service
Bug #489078 reported by
Stuart Bishop
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
teampartici
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
lp://qastaging/~stub/launchpad/auth-mirror-tables
- Guilherme Salgado (community): Approve (release-critical)
- Graham Binns (community): Approve
- Canonical Launchpad Engineering: Pending (release-critical) requested
-
Diff: 1161 lines (+987/-75)6 files modifieddatabase/replication/helpers.py (+10/-2)
database/sampledata/current-dev.sql (+411/-38)
database/sampledata/current.sql (+363/-35)
database/schema/patch-2207-15-1.sql (+28/-0)
database/schema/patch-2207-16-0.sql (+50/-0)
database/schema/trusted.sql (+125/-0)
tags: | added: current-rollout-blocker |
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.
We want to land this cycle to ensure we keep to the login service timeline.