CloudServices/Meetings/2011-05-03
From MozillaWiki
< CloudServices | Meetings
- Time: Tuesday at 9:15 AM PST / 12:15 PM EST / 5:15 PM UTC.
- Place: Mozilla HQ, North Bridge
- Phone (US/Intl): 650 903 0800 x92 Conf: 8616#
- Phone (Toronto): 416 848 3114 x92 Conf: 8616#
- Phone (US): 800 707 2533 (pin 369) Conf: 8616#
Who's away?: rnewman.
Contents
- 1 Technical
- 1.1 Ops
- 1.2 Engineering
- 1.2.1 Python Sync Server (Tarek)
- 1.2.2 Python Registration Server (reg/sreg) (Tarek)
- 1.2.3 PHP Sync Server (Toby)
- 1.2.4 Identity Server (JR/rnewman)
- 1.2.5 F1 (Share) (Philipp/Tarek)
- 1.2.6 Firefox Home (Stefan)
- 1.2.7 Sync Client (rnewman/philikon)
- 1.2.8 Monitoring and Blocking (rtilder)
- 1.2.9 Notifications (Shane/Alex)
- 1.2.10 QA (tracy)
- 2 Deployment Requests
- 3 Metrics
- 4 Product
- 5 Security
- 6 Marketing
- 7 Roundtable
Technical
Ops
Engineering
Python Sync Server (Tarek)
- waiting for the bench server
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)
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.
- 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)
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)
Notifications (Shane/Alex)
- Neither of us are here anymore, but thanks for still putting our names in the header :)
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
As per the production release process any production change requests for the next release window (Monday afternoon) must be called out here by the developer requesting the update, with all required bugs/test plans already complete by the start of the meeting.
- keyexchange 0.3-1, bug 650328
- Python Registration Server, bug 654148
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
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 654160