Confirmed users
358
edits
User:Mconnor/BIDSync(s): Difference between revisions
→Storage API v2.0
| Line 247: | Line 247: | ||
==== Risks ==== | ==== Risks ==== | ||
* High-volume crypto at scale is tricky | * High-volume crypto at scale is tricky | ||
=== Storage API v2.0 === | === Storage API v2.0 === | ||
| Line 261: | Line 262: | ||
* Document and implement changes to 2.0 API (almost all unused feature removal) | * Document and implement changes to 2.0 API (almost all unused feature removal) | ||
* Take the clean-room opportunity to fix some long-standing database problems | * Take the clean-room opportunity to fix some long-standing database problems | ||
==== Work Breakdown ==== | |||
===== Design and Document the 2.0 Protocol API ===== | |||
* This is mostly done already, as it's just some cleanup and removal of unused features. | |||
* The API may change a little based on client developer feedback..? | |||
* Estimate: 1 day, then tweaking as needed in parallel with other tasks. | |||
===== Migrate server-storage to pyramid/cornice/mozsvc ===== | |||
* This involves replacing the use of server-core with our new pyramid-based libraries. | |||
* Based on account-portal experience, the backend code can remain pretty much unchanged. | |||
* It should be possible to pass almost all of the existing test suite with the new core. | |||
* No protocol changes implemented yet, one thing at a time! | |||
* Estimated Time to Testability: 2 days. | |||
* Then testing/bugfixing as other work progresses. | |||
===== Consume Sagrada Tokens ===== | |||
* In theory this means just plugging in the "token processing library" described below. | |||
* Current token design includes no metadata, just the UID - so do we still need to look up the other details in LDAP? | |||
* Estimated Time To Testability: 1 day, assuming token processing library is ready and working... | |||
===== Implement the 2.0 Protocol API ===== | |||
* Some of the changes we get for free by using cornice. | |||
* Others will be small self-contained amounts of work, e.g. rename headers, change urls, etc. | |||
* Needs new logging infrastructure, since URL/header changes make zeus logs unusable for metrics. | |||
* Estimated Time To Testability: 2 days. | |||
===== Deploy for Client Testing ===== | |||
* At this point, clients can start developing/testing against the new protocol. | |||
* We should get something up and running for them to test against. A local server? A dev VM? | |||
===== Implement new database backend ===== | |||
* Purely internal, clients should see no changes at this point. | |||
* Heavily based on existing SQL backend, but with some simplifications. | |||
* Need to coordinate with ops to update DB management scripts. | |||
* Also need to investigate impact on the memcached layer. | |||
* Estimated Time To Testability: 3 days. | |||
===== Fixing other Known Bugs ===== | |||
* Once the necessary changes are in place, we should focus on existing server bugs. | |||
* Particularly any that will help reduce problems during the launch: | |||
* database connection closing/timeout improvements | |||
* defering of deletes to a background process | |||
* quota management | |||
* others...? | |||
==== Target Timeline ==== | ==== Target Timeline ==== | ||
| Line 266: | Line 319: | ||
==== Risks ==== | ==== Risks ==== | ||
* Because users will reupload all their stuff, FF launch day is likely to be a heavy, heavy data day. | * Because users will reupload all their stuff, FF launch day is likely to be a heavy, heavy data day. | ||
* The use of a separate metadata token is currently undefined, it's not clear how or when that will fit into this plan. | |||
=== Metrics (metlog) === | === Metrics (metlog) === | ||