Snappy Symbolication Server: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 8: Line 8:
{{FeatureTeam
{{FeatureTeam
|Feature feature manager=bsmedberg
|Feature feature manager=bsmedberg
|Feature lead engineer=bsmedberg for now
|Feature lead engineer=bgirard
|Feature additional members=vladan, ehsan, benwa
|Feature additional members=vladan, ehsan, benwa
}}
}}
Line 20: Line 20:
2) the client page about:snappy will use this to convert numeric stacks into symbols
2) the client page about:snappy will use this to convert numeric stacks into symbols
|Feature functional spec=Stack data will be submitted to the server in JSON format and will be returned in JSON format. Details TBD as we iterate.
|Feature functional spec=Stack data will be submitted to the server in JSON format and will be returned in JSON format. Details TBD as we iterate.
|Feature implementation plan=1) get a VM for experimentation/development with access to the symbol data and node
|Feature implementation plan=# get a VM for experimentation/development with access to the symbol data and node COMPLETE
2) develop the webservice behind the firewall
# develop the webservice behind the firewall INITIAL CODE COMPLETE, NEEDS REVISION FOR DIRECT SYMBOL ACCESS - The code is currently hosted at https://github.com/bgirard/ProfilerSymbolServer
3) After development is complete, open up the webservice via a public URL
# After development is complete, open up the webservice via a public URL
|Feature security review=Hopefully minimal security review will be required. The webservice can run with readonly mounts in an isolated environment and should not have any private or persistent data.
|Feature security review=Hopefully minimal security review will be required. The webservice can run with readonly mounts in an isolated environment and should not have any private or persistent data.
|Feature privacy review=No private information will be processed.
|Feature privacy review=No private information will be processed.

Revision as of 20:53, 23 February 2012

Please use "Edit with form" above to edit this page.

Status

Snappy Symbolication Server
Stage Feature Inbox
Status In progress
Release target Nightly 13
Health OK
Status note `

{{#set:Feature name=Snappy Symbolication Server

|Feature stage=Feature Inbox |Feature status=In progress |Feature version=Nightly 13 |Feature health=OK |Feature status note=` }}

Team

Product manager `
Directly Responsible Individual bsmedberg
Lead engineer bgirard
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members vladan, ehsan, benwa

{{#set:Feature product manager=`

|Feature feature manager=bsmedberg |Feature lead engineer=bgirard |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=vladan, ehsan, benwa }}

Open issues/risks

`

Stage 1: Definition

1. Feature overview

In nightly profiling builds (and perhaps later in regular nightlies and aurora) we want to give users the ability to profile their own slowness via an about:snappy page. We also want to submit significant chrome hangs to telemetry.

2. Users & use cases

In order to make this useful, the reports need to be able to map stack traces to symbols, similarly to how crash-stats does this. However, we're not taking full minidumps for privacy reasons, so we want to expose a webservice based on crash-stats symbol data that can convert address/offset information to a symbolicated name.

There will be two users of this data:

1) the telemetry server will use this to convert numeric stacks into symbols 2) the client page about:snappy will use this to convert numeric stacks into symbols

3. Dependencies

`

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

Stack data will be submitted to the server in JSON format and will be returned in JSON format. Details TBD as we iterate.

6. User experience design

`

Stage 3: Planning

7. Implementation plan

  1. get a VM for experimentation/development with access to the symbol data and node COMPLETE
  2. develop the webservice behind the firewall INITIAL CODE COMPLETE, NEEDS REVISION FOR DIRECT SYMBOL ACCESS - The code is currently hosted at https://github.com/bgirard/ProfilerSymbolServer
  3. After development is complete, open up the webservice via a public URL

8. Reviews

Security review

Hopefully minimal security review will be required. The webservice can run with readonly mounts in an isolated environment and should not have any private or persistent data.

Privacy review

No private information will be processed.

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |Feature overview=In nightly profiling builds (and perhaps later in regular nightlies and aurora) we want to give users the ability to profile their own slowness via an about:snappy page. We also want to submit significant chrome hangs to telemetry. |Feature users and use cases=In order to make this useful, the reports need to be able to map stack traces to symbols, similarly to how crash-stats does this. However, we're not taking full minidumps for privacy reasons, so we want to expose a webservice based on crash-stats symbol data that can convert address/offset information to a symbolicated name.

There will be two users of this data:

1) the telemetry server will use this to convert numeric stacks into symbols 2) the client page about:snappy will use this to convert numeric stacks into symbols |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=Stack data will be submitted to the server in JSON format and will be returned in JSON format. Details TBD as we iterate. |Feature ux design=` |Feature implementation plan=# get a VM for experimentation/development with access to the symbol data and node COMPLETE

  1. develop the webservice behind the firewall INITIAL CODE COMPLETE, NEEDS REVISION FOR DIRECT SYMBOL ACCESS - The code is currently hosted at https://github.com/bgirard/ProfilerSymbolServer
  2. After development is complete, open up the webservice via a public URL

|Feature security review=Hopefully minimal security review will be required. The webservice can run with readonly mounts in an isolated environment and should not have any private or persistent data. |Feature privacy review=No private information will be processed. |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority Unprioritized
Rank 999
Theme / Goal Performance
Roadmap Platform
Secondary roadmap `
Feature list Platform
Project Responsiveness
Engineering team `

{{#set:Feature priority=Unprioritized

|Feature rank=999 |Feature theme=Performance |Feature roadmap=Platform |Feature secondary roadmap=` |Feature list=Platform |Feature project=Responsiveness |Feature engineering team=` }}

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-needed a review needs to be scheduled
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=sec-review-needed |Feature security health=` |Feature security notes=a review needs to be scheduled |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}