canmove, Confirmed users
1,173
edits
CloudServices/Meetings/2011-05-03: Difference between revisions
CloudServices/Meetings/2011-05-03 (view source)
Revision as of 20:06, 19 November 2013
, 19 November 2013Telliott moved page Services/Meetings/2011-05-03 to CloudServices/Meetings/2011-05-03
m (Telliott moved page Services/Meetings/2011-05-03 to CloudServices/Meetings/2011-05-03) |
|||
| (21 intermediate revisions by 10 users not shown) | |||
| Line 19: | Line 19: | ||
=== Python Sync Server (Tarek) === | === Python Sync Server (Tarek) === | ||
* waiting for the bench server | |||
=== Python Registration Server (reg/sreg) (Tarek) === | === Python Registration Server (reg/sreg) (Tarek) === | ||
* | * Push planned for next Monday, as requested in {{bug|654148}} (discussion of doing it in Wikis rather than in the bug. Will coordinate to set one up in the appropriate location) | ||
=== PHP Sync Server (Toby) === | === PHP Sync Server (Toby) === | ||
Nothing new here. Chugging along | |||
=== Identity Server (JR/rnewman) === | |||
* helped st3fan bring up a stand alone server | |||
* reworked some config information and docs to help future folks. | |||
* did not succeed in getting up ddahl, but provided credentials for work. | |||
* touched base w/ thunder regarding ID server future and how it was recv'd in Germany. | |||
* moved redis storage backend rebuild as secondary concern. | |||
* security review for ID server (no massive changes required) | |||
Next: | |||
* Get new intern (Paul) up to speed and figure out what he'll be working on. | |||
* resolve config issue with OIDserver and multiple middleware. | |||
* start work on new ID server task list per Thunder. | |||
=== F1 (Share) (Philipp/Tarek) === | === F1 (Share) (Philipp/Tarek) === | ||
* Server (tarek): | |||
** working on service status DB [tarek] | |||
** working on more repo reorg [tarek] | |||
* Client (philikon): | |||
** not much progress on fx-share, was PTO 3 days last week | |||
** working on {{bug|646658}}, {{bug|650201}}, {{bug|642674}}, expecting to finish this week | |||
=== Firefox Home (Stefan) === | === Firefox Home (Stefan) === | ||
=== Sync Client (rnewman) === | === Sync Client (rnewman/philikon) === | ||
* rnewman: Not too much (jsconf). Still working on async when I get a chance; Philipp can give overview of changes since last time! | |||
* philikon: handed off s-c to QA yesterday, expecting to merge today. Marina is making us look bad (3 out of 4 bugs fixed were hers!) | |||
=== Monitoring and Blocking (rtilder) === | === Monitoring and Blocking (rtilder) === | ||
=== Notifications (Shane/Alex) === | === Notifications (Shane/Alex) === | ||
* Neither of us are here, but thanks for still putting our names in the header :) | * Neither of us are here anymore, but thanks for still putting our names in the header :) | ||
=== QA (tracy) === | === QA (tracy) === | ||
* Sync s-c client sign-off EOD today (5/3) | |||
* Hand-off from server team on Wednesday. We'll sign-off by EOD Friday (5/6) | |||
* Tony is in Romania, then London this week. | |||
* Working on test plan for Identity based on project docs and mockups. | |||
* {{bug|524091}} Killing Microsummaries patch by places Team. Will test around scenarios and backward compatibility with this weeks s-c builds. | |||
= Deployment Requests = | = Deployment Requests = | ||
| Line 53: | Line 76: | ||
* keyexchange 0.3-1, {{bug|650328}} | * keyexchange 0.3-1, {{bug|650328}} | ||
* Python Registration Server, {{bug|654148}} | * Python Registration Server, {{bug|654148}} | ||
= Metrics = | = Metrics = | ||
;Metrics Data Collection Module - Collection Server | |||
:The collection server is in testing and should be ready to release a staging instance ready to accept light amounts of Telemetry data by week end. We are still conducting some load tests and will finalize our implementation based on the results of those tests. The API is a simple POST or PUT request with the URL http(s?)://<server>/<collection_id>/<payload_id> and the body is of MIME type application/json and the value is a JSON string. An example collection_id could be just "telemetry" or it could be more granular per your needs. The payload_id is a unique identifier for this particular payload to prevent duplicate submissions. It is not intended to be a unique ID for the user. Daniel had a discussion with Taras on this and it was suggested that this could be used to incrementally deliver telemetry data during a session with the ID being reset whenever the session was deemed by the client to be finished. | |||
= Product = | = Product = | ||
= Security = | = Security = | ||
Mozilla ID Threat Model Completed - https://wiki.mozilla.org/Security/Reviews/MozillaID#Threat_Model | |||
F1 Threat Modeling in progress | |||
InfraSec planning for security reviews of weekly train bug [https://bugzilla.mozilla.org/show_bug.cgi?id=654160 654160] | |||
= Marketing = | = Marketing = | ||