Auto-tools/Projects/Charts: Difference between revisions

← Older edit

Auto-tools/Projects/Charts (view source)

Revision as of 22:35, 15 December 2014

4,015 bytes added , 15 December 2014

simple highlight

Klahnakoski

Confirmed users

513

edits

@@ Line 1: / Line 1: @@
-= charts.mozilla.org =
+= Overview of charts.mozilla.org =
+This project is responsible for presenting the dashboards and details required by management to track progress on the B2G releases and highlight possible bottlenecks in development.
-== Overview ==
+This project is highly visible to the FirefoxOS team, and Mozilla in general.
-The charts application is pure javascript running on the client side.  It accesses a separate ElasticSearch cluster for data.
-== Architecture ==
+= Hacking/Contribution =
-=== Web Server ===
+If you are good at making elegant UI, or are familiar with client side web frameworks, '''and''' you like having your work front-and-center (along with all the accolades and "constructive" feedback that comes with it) then this project is for you!
+Contributing to charts.mozilla.org has some distinct benefits over other projects:
+* Your work is highly visible to people working at Mozilla
+* The pages are static HTML and Javascript; and can be deployed fast
+* Assuming you already know Javascript; there is a small learning curve.
+* Setting up a development environment is very simple
+== Code ==
+The [https://github.com/mozilla/charts code and setup instructions] can be found on Github.  Since these are simple static pages, you will find it quite easy.
+==Contact==
+You can contact me, Kyle Lahnakoski
+:'''IRC:''' ekyle@irc.mozilla.org (in #ateam)
+:'''email:''' klahnakoski@mozilla.com
+I am available to get you started and discuss bus that you may find interesting.
+==Good First Bugs==
+This is a current list of bugs (from Bugzilla) that have been marked as simple, and exist primarily to ensure you are familiar with Github and the pull request process.
+<div>
+<bugzilla>
+{
+"include_fields": "id, summary, status, resolution, assigned_to",
+"resolution":"---",
+"f1":"blocked",
+"o1":"equals",
+"v1":1014275,
+"f2":"status_whiteboard",
+"o2":"anywordssubstr",
+"v2":"[good first bug]"
+}
+</bugzilla>
+</div>
+==All Open Issues==
+This is a list of bugs that are more involved.  Please read through them to get an idea of where we would like to go with this project.
+<div>
+<bugzilla>
+{
+"include_fields": "id, summary, status, resolution, assigned_to",
+"resolution":"---",
+"f1":"blocked",
+"o1":"equals",
+"v1":1014275
+}
+</bugzilla>
+</div>
+= Architecture =
+The '''charts.mozilla.org''' application is a pure Javascript client running on the browser.  It accesses the [https://wiki.mozilla.org/BMO/ElasticSearch BMO/ES] cluster for data.
+== Web Server ==
 [[image:Auto_tools_Projects_Charts_Architecture.png|right|thumb|200px]]
-The application itself is served as a set of static html and javascript files from the Mozilla PAAS Stackato servers.  There are two versions: Production and Staging, the latter will usually have more features, while being slightly more buggy. Please us the staging server as much as possible: Like the Nighly Firefox, using staging will help find bugs sooner.
+The application itself is served as a set of static html and javascript files from the Mozilla PAAS Stackato servers.  There are two versions, Production and Staging; the latter will usually have more features, while being slightly more buggy. Please use the staging server as much as possible: like Firefox Nightly, using staging will help find bugs sooner.
 Code for each version is in a separate branch
 {| class="wikitable"
 |-
-! Server !! Source Code
+! Server !! URL !!Source Code
 |-
-| production || https://github.com/mozilla/charts
+| production || http://charts.mozilla.org/ ||https://github.com/mozilla/charts
 |-
-| staging || https://github.com/mozilla/charts/tree/allizom
+| staging || http://charts.paas.allizom.org/ ||https://github.com/mozilla/charts/tree/allizom
 |}
-Really, it does not matter where the application is served from (I have various development versions on my people page).  If both these servers are down, a simple <code>git clone</code> can allow you to "serve" the app directly from your local  filesystem.
+Since the app is entirely client-side, it does not matter where the application is served from (I have various development versions on my people page).  If both these servers are down, a simple <code>git clone</code> can allow you to "serve" the app directly from your local  filesystem.
-=== esFrontline ===
+== esFrontline ==
-esFrontline is a simple python based proxy to limit ES requests to search requests and limit the indexes exposed. Other than these restrictions, ''this proxy is invisible to client application''.  See https://wiki.mozilla.org/BMO/ElasticSearch for more details.
+esFrontline is a simple Python-based proxy to limit ES requests to search requests and limit the indexes exposed. Other than these restrictions, ''this proxy is invisible to client application''.  See https://wiki.mozilla.org/BMO/ElasticSearch for more details.
-=== ElasticSearch Clusters ===
+== ElasticSearch Clusters ==
 Once the application is downloaded it will attempt to contact both the private and public clusters simultaneously; whichever responds will be chosen for all future connections, with preference given to the private cluster.  The queries for the dashboard are then sent to the cluster as the dashboard app requires.
 The clusters are configured to accept requests from any client.  Hopefully this will promote development of alternative dashboards and charts.
-=== Development ===
+== Development ==
 The Development server is responsible for secondary indexes built from the main <code>bug_version</code>.  Currently it maintains the hierarchy index for determining recursive dependencies on bugs.
-=== Slowness ===
+== Slowness ==
 There are some sources of slowness:
@@ Line 40: / Line 95: @@
 * Code - Nothing is minimized, some pages even pause to load JavaScript dynamically.
-== Past Problems ==
+= Production Support =
-=== CORS ===
+Is there a problem with production?  Read on...
+== Points of Contact for Technical Issues ==
+* For problems with the application itself, e.g. 404 errors, see cturra or others in #paas on irc.
+** To restart PaaS, use the [https://api.paas.allizom.org/console/overview/ Stackato web console]
+** To upload a new image:
+**# <code>git clone https://github.com/mozilla/charts.git</code>
+**# Use the <code>stackato.yml</code> image to deploy:
+:::: stackato target api.paas.allizom.org
+:::: stackato login
+:::: stackato update
+* For problems with the database, e.g. basic framework loads but no data appears, see jakem, cyliang, or fubar in #it on irc.
+== Instructions ==
+* [https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=30081453#MozillaPaaS%28Stackato%29-ObtainingandInstallingtheClient Stackato Instructions on Mana]
+* [https://api.paas.allizom.org/console/overview/ Stackato web console ]
+= Past Problems =
+== CORS ==
 The charts application makes cross-platform requests: The app is served from charts.mozilla.org and data requested from esfrontline.bugzilla.mozilla.org.  This requires the various proxy servers (not shown in architecture) ensure the <code>Access-Control-Allow-Origin</code> HTTP response header be set appropriately.  In the past it has been shown this header is stripped from the esFrontline response and set according to Operations' guidelines.
+== Clusters Down or Not Responding ==
+ElasticSearch is still prone to OutOfMemoryExceptions.  Occasionally, this will bring down nodes in the cluster.  '''The best solution has always been to reboot the problem nodes''' (or all of them).
+The chance of data loss is very low:  First, the data is replicated 2 times (for a total of three copies).  Second, the ETL daemon (responsible for filling the cluster) performs some simple data checks, and writes full history of all changed bugs: Effectively overwriting corruption on any bugs that does occur.  Corruption on inactive bugs can linger; assuming corruption exists, and assuming a change happened when the cluster was misbehaving, and assuming the ETL did not detect the misbehavior.  Third, there are consistency checks built into MoDevMetrics that monitors or consistency between bug versions, corruption is sometimes detected, and inevitably fixed by the next ETL run.