Canonical SSO and Launchpad share database tables

[Gary Poster]

Currently, we mirror selected Launchpad information to the lp_* 'mirror' tables. These tables are then replicated using Slony-I to the CanonicalSSO databases.

At a minimum, the CanonicalSSO systems need to stop using the lp_Account table to map OpenId Identifiers to Launchpad Person data (such as TeamParticipation). The CanonicalSSO could use a mirror of the Launchpad EmailAddress information to map CanonicalSSO accounts to Launchpad information, or some entirely different mechanism allowing us to seperate the CanonicalSSO and Launchpad databases into separate replication clusters.

This is step 3 of https://dev.launchpad.net/LEP/OpenIdRoadmap, but also tech debt it its own right.

[Robert Collins (lifeless)]

Our DB downtime is downtime for SSO while they share a replication cluster; fixing that is important.

[William Grant (wgrant)]

The new plan is that SSO will get Launchpad ID, timezone, and team memberships from LP using XML-RPC. If Launchpad is down during login, SSO will not return that extra information.

[Francis J. Lacoste (flacoste)]

> If Launchpad is down during login, SSO will not return that extra information.

That looks like a problem to me. Many, many, many things are protected by Launchpad team restriction. That means that all of these resources become unavailable whenever Launchpad is unavailable. I'm not sure that's a limitation we are willing to live with.

I'd clarify with at least James from IS before switching to this new API.

[Robert Collins (lifeless)]

On Wed, Feb 15, 2012 at 8:19 AM, Francis J. Lacoste
<email address hidden> wrote:
>> If Launchpad is down during login, SSO will not return that extra
> information.
>
> That looks like a problem to me. Many, many, many things are protected
> by Launchpad team restriction. That means that all of these resources
> become unavailable whenever Launchpad is unavailable. I'm not sure
> that's a limitation we are willing to live with.
>
> I'd clarify with at least James from IS before switching to this new
> API.

So, this was discussed with the SSO team lead; SSO has *more* downtime
than LP at the moment, and LP has -now- got an excellent track record
for being up, reliably, with schema changes being a 90-240 second
downtime.

Things like RT have a fallback mechanism for IS themselves to bootstrap.

SSO *and* LP teams both want SSO to stop doing LP team reporting and
have that be done by consumers checking directly with LP... so this
API is going to be 'short lived' [some years probably] anyhow.

I will double check with James, but I'm quite sure this won't degrade
SSO uptime to unacceptable levels.

-Rob

[Robert Collins (lifeless)]

I've talked with James and other than a couple of tweaks to the plan
(make requests fail-hard; good error UI (tells folk to retry in 60
seconds)) he is ok with it given the benefits and LP's current
reliability.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r14801 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14801>.