|
|
| Line 216: |
Line 216: |
| == Backward Compatibility == | | == Backward Compatibility == |
|
| |
|
| XXX TBU
| | The Login server uses the same snode and ldap servers, so both authentication systems can cohabit during a transition period. |
| | |
| Older versions of the system will use completely different API entrypoints - the old /user api, and the 1.1 /sync api. Those will need to be maintained during the transition, though new clusters should spin up with only 2.0 support.
| |
| | |
| We should watch logs to study 1.1 falloff and consolidate those users through migration as they diminish.
| |
| | |
| However, There are a couple of points that need to be synced up:
| |
| | |
| * The database that assigns nodes needs to be shared between the two. We should add a column for "1.0 acceptable" and update the old system to only look at those columns. Alternately, could work with ops to just have an "all old assignments go to this one cluster", in which case, the db doesn't need to be shared.
| |
| | |
| * There will be a migration that moves all the user node data from LDAP to the tokenserver. However, we need to make sure that any subsequent migrations update this data. This ensures that a user with a pre-2 client and post-2 client point at the same place, and that people moving to the new systems will have the right node. We can't punt this, because if a node goes down post-migration, a user who switches over afterwards is stuck on it. (at the very least, we need to purge these nodes from the 2.0 db).
| |
| | |
| * will need to migrate all user login data over to the browserid servers, but that's not relevant to tokenserver.
| |
|
| |
|
| == Infra/Scaling == | | == Infra/Scaling == |