Sever ShipIt/Launchpad links

[Gary Poster]

(Please keep this a private bug so it is easier to talk about implementation choices. Some aspects of this are confidential. Please discuss with Gary Poster or Stuart Metcalfe before making it public again.)

ShipIt is no longer being maintained by the Launchpad team but is still tied into the Launchpad data model. This makes it difficult to refactor parts of the Launchpad data model and ties ShipIt rollouts to Launchpad rollouts.

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

[Gary Poster (gary)]

I talked with Stuart Metcalfe and Salgado about this. Highlights follow.

Right now, the shipit code itself relies on these tables: Account, EmailAddress, Country, Karma, and (in order to get to Person).

The karma is used to decide whether or not the user is "trusted" on shipit. Trusted users are allowed to ask for more CDs than regular users. A user is trusted if they have X karma or are ubuntu members.

Karma is in the webservice API, but not the way that shipit uses it (it counts karma entries, while the webservice gives total karma points).

One way of simplifying the problem would be to get approval to ignore karma. Then it could just get team membership from openid to see if the user were a member of the ubuntu team. Circumstances might make this acceptable. It will simply mean fewer people allowed to order more than a couple CDs.

Team membership and the account and email address information can be obtained from openid. Alternatively, and perhaps more easily, shipit could share access to the replicated tables that the openid provider uses.

That would just leave the Country table, which is relatively static, and would not have to stay in sync with Launchpad.

All three of us agree at this time that it would make sense under the current circumstances to have shipit fork Launchpad code, rather than trying to keep up with trunk.

All of the above doesn't sound too bad. However, the biggest risk is that shipit relies on some Launchpad code, and that Launchpad code might fall over when the rest of the database is not around. We don't know. If it does fall over, we don't know how easy it will be to fix it.

Salgado will be happy to offer advice, but will not be available for any of the actual work.

[Robert Collins (lifeless)]

On the karma side, shipit counting entries seems like a buggy
approach: the karma tables are meant to be transient and decay over
time... perhaps it counts as a way to avoid an old perf bug which the
karmacache would avoid?

[Gary Poster (gary)]

Stuart says he thinks we could do this relatively easily.

- make sure that we currently only rely on Launchpad updates for karma (IOW, that copying the DB tables will be sufficient, not replicating)

- fork LP code for shipit

- Reports we generate every week currently store their output in the Librarian. We either can forget about this or store them somewhere else.

- Change approval algorithm to be simpler (ignore karma and maybe just look at team from openid--sends fewer CDs so less money)

- copy 16 DB tables (no further replication needed)

- test

[Stuart Metcalfe (stuartmetcalfe)]

It might make more sense to expose LP karma through SSO with an openid extension as it would also be re-usable by community sites as well as shipit. We *could* obtain this using the LP API rather than copying tables, if we have a good UI for users to manage the association from SSO and if we solve bug #655565.

[William Grant (wgrant)]

We went further and severed ShipIt from reality itself instead.