Firefox/Push/Progress Report/2017Q3: Difference between revisions

Firefox/Push/Progress Report/2017Q3 (view source)

Revision as of 18:36, 13 September 2017

26 bytes removed , 13 September 2017

Updated with Sept 13 confidence levels

Juliemccracken

670

edits

@@ Line 1: / Line 1: @@
 __NOTOC__
-<big><big>'''August 2, 2017'''</big></big>
+<big><big>'''September 13, 2017'''</big></big>
 == Q3 OKR Progress ==
@@ Line 25: / Line 25: @@
 |align="center"|50%
 |align="center"|50%
-|align="center"|
+|align="center"|50%
-|align="center"|
+|align="center"|50%
-|align="center"|
+|align="center"|20%
 |align="center"|
 |align="center"|
@@ Line 34: / Line 34: @@
 *[https://github.com/mozilla-services/push-okr/issues/39 Issue 39: Create an API Layer for Ardere]
 |
-*Work has not begun yet but still sufficient time to complete by end of the quarter.
+*No progress yet this quarter with only a couple weeks to go, busy with other higher priority things (us and QA still get by w/ ardere sans API layer).
+*Can we crank anything out in a couple weeks?
 |-
 |align="left"| 1.2 Create a "smoke-test" for the service, a quick test that verifies it’s up and running.
 |align="center"|50%
 |align="center"|50%
-|align="center"|
+|align="center"|80%
-|align="center"|
+|align="center"|80%
-|align="center"|
+|align="center"|80%
 |align="center"|
 |align="center"|
@@ Line 49: / Line 50: @@
 *[https://github.com/mozilla-services/push-service/issues/73 Issue 73: Rebuild testing python script for webpush]
 |
-*Work has begun.
+*Work is effectively done but need to get feedback from chartjes before increasing confidence level.
-* Created [https://github.com/mozilla-services/push-test push-test], but will fork ap-loadtest to create far better version.
 |-
 |align="left"| 1.3 Github/Jenkins API call integration with Ardere
 |align="center"|50%
 |align="center"|50%
-|align="center"|
+|align="center"|50%
-|align="center"|
+|align="center"|50%
-|align="center"|
+|align="center"|20%
 |align="center"|
 |align="center"|
@@ Line 70: / Line 70: @@
 |align="center"|60%
 |align="center"|65%
-|align="center"|
+|align="center"|70%
-|align="center"|
+|align="center"|70%
-|align="center"|
+|align="center"|80%
 |align="center"|
 |align="center"|
@@ Line 81: / Line 81: @@
 *[https://github.com/mozilla-services/autopush/issues/802 Issue 802: determine cause of memory leak on pypy (especially connection) nodes]
 |
-*Have done some planning.
+*Have a lot more detail of our usage patterns now from various load test runs under valgrind massif/leakcheck.
+*Need to further analyze results and push forward the easily reproducible parts.
 |-
 | align="left"|2.2 Code in PyPy that allows us to dump detailed object graphs of allocated Python objects.
@@ Line 89: / Line 90: @@
 |align="center"|50%
 |align="center"|50%
-|align="center"|
+|align="center"|52%
-|align="center"|
+|align="center"|52%
-|align="center"|
+|align="center"|60%
 |align="center"|
 |align="center"|
@@ Line 98: / Line 99: @@
 *[https://github.com/mozilla-services/push-okr/issues/43 Issue 43: PyPy object graph memory dumps]
 |
-*Still working on getting an SOW in place with the contractor. Movement through the CASA process has been slow. There is an open question re. how many hours this contractor will deliver in the calendar year for Mozilla as a whole.
+*Contract finalized, beginning to work with contractor now.
+*On the right track now, but will be a stretch to finish the objective before end of quarter.
 |-
 | align="left"|2.3 Create a graph showing the delta for memory consumption over time on a per-release basis.
 |align="center"|80%
 |align="center"|90%
-|align="center"|
+|align="center"|90%
-|align="center"|
+|align="center"|90%
-|align="center"|
+|align="center"|90%
 |align="center"|
 |align="center"|
@@ Line 112: / Line 114: @@
 *[https://github.com/mozilla-services/push-okr/issues/44 Issue 44: Dashboard for memory use over time]
 |
-*Have a dashboard that provides this information.
+*Still on track. Need to set aside time to make the graph.
-*Need to makes some changes to display the graphs all in a row (to show memory consumption on a per release basis).
 |-
 |rowspan=4|3. Reduce costs
@@ Line 119: / Line 120: @@
 |align="center"|80%
 |align="center"|80%
-|align="center"|
+|align="center"|90%
-|align="center"|
+|align="center"|90%
-|align="center"|
+|align="center"|100%
 |align="center"|
 |align="center"|
@@ Line 129: / Line 130: @@
 *[https://github.com/mozilla-services/autopush/issues/978 Issue 978 Create distilled threaded logic for websocket server for Rust PoC]
 |
-*Plan has been created and is in the process of being implemented.
+*Far enough that this is basically done now (100%).
 |-
 | align="left"|3.2 Spec a Rust <-> Python API of Rust PoC.
 |align="center"|80%
 |align="center"|100%
-|align="center"|
+|align="center"|100%
-|align="center"|
+|align="center"|100%
-|align="center"|
+|align="center"|100%
 |align="center"|
 |align="center"|
@@ Line 143: / Line 144: @@
 *[https://github.com/mozilla-services/push-okr/issues/46 Issue 46: Spec a Rust <-> Python API of Rust PoC]
 |
-*API is spec’d out. Have started implementing it.
+*Done
 |-
 | align="left"|3.3 Kill Simplepush.
 |align="center"|60%
 |align="center"|90%
-|align="center"|
+|align="center"|90%
-|align="center"|
+|align="center"|93%
-|align="center"|
+|align="center"|100%
 |align="center"|
 |align="center"|
@@ Line 159: / Line 160: @@
 *[https://github.com/mozilla-services/autopush/issues/886 Issue 886: Obsolete UDP functions from autopush]
 |
-*Last rollout we introduced the flag to turn it off.
+*Rolled it out this past week and have heard no complaints.
-*At this point we can turn it off at any point.
 |-
 | align="left"|3.4 Relax VAPID checks for partner endpoints.
 |align="center"|60%
 |align="center"|100%
-|align="center"|
+|align="center"|100%
-|align="center"|
+|align="center"|100%
-|align="center"|
+|align="center"|100%
 |align="center"|
 |align="center"|
@@ Line 175: / Line 175: @@
 *[https://github.com/mozilla-services/autopush/issues/938 Issue 938: Don't check Vapid sig value for partner endpoint users]
 |
-* Rolled out on stage for testing purposes but haven’t done it for any partners yet.
+*Done
 |-
 |}