Snappy Symbolication Server

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-sched	2012.03.02
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-sched |Feature security health=` |Feature security notes=2012.03.02 |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=` }}