jmaher / alert_manager Goto Github PK

currently this is a static piece of text, it would be easier to work with alert manager if we could click on the revision and view just that revision

currently if you click on a row it opens a pop up for comments and once you close the pop up the page refreshes which should not happen.

right now we pull all data, we should default to 2 months (60 days). that will make queries faster and the UI more usable.

For filtering, we should stick to this as well, but if we do that, we need a method to adjust the time range we are looking at. (another option in the topnav bar possilbly

I would like to ability to filter the results by platform, with 2 ways to view it:

1. url parameter: &platform=linux64
2. a top line search filter- this doesn't exist, so we would need to add a static div at the top that would have filters for available platforms (with the current one selected). Upon selection it would filter the UI

this will keep state in the top nav bar for what we are filtering on. Also, this will then allow us to quickly narrow down the search if needed.

there is a bug that if you accidentally mark a status of an alert to resolved, it won't show up. If you try to mark it as new again, it doesn't change. I would like to ensure that you can always change the state of an alert and it would reset all appropriate fields in the database.

when a bugzilla bug is resolved it would be nice to go in and verify it is and mark the alert as resolved/fixed. This would be easier if we could detect this automatically, here is a general workflow:

1. create a python script that queries all bugs from the database where the status = 'investigating'
2. in this script use the bugzilla api to query the status of each bug
3. build a 'conflict' list of all bugs that are resolved
4. create a field in the alert table that we can use as a flag for bug_conflict- set that to true for all alerts that have a bug in the conflict list

the alert manager supports some url params, I would like to support rev:
http://54.215.155.53:8080/alerts.html?rev=cd8697531517

This would show all the alerts for that specific revision.

Right now there are 2 types of hidden alerts:

• merged alerts (detected automatically)
• closed alerts

I would like to ensure that when we add showAll=1 to the url that we can see all types of hidden alerts.

I think that if we select a platform, it would be nice to see all tests which have regressions for that given platform instead of the entire list of possible tests. Likewise this filtering should take place for any option given (rev, test, platform).

it was be easier to find a test in the test drop down if it was sorted alphabetically. As for revisions, they should be sorted by date ideally.

I would like to have a simple visible method to view all bugs in the conflict state (where the bug is resolved in the bug database, but not in the alert table).

We could add a red ! and/or mark the entire bug in a red or increased font :)

Ideally I would like a new page or a way to query just the conflict bug/alerts so I can go through and clean them up on a regular basis.

This is the default sorting for the views prior to the filtering, and currently without the filtering.

right now the UI is layed out from left to right:
date, branch, test, platform, percent, graphurl, changeset, tbplurl, bug,status

I would like to see, graphurl, changeset, tbplurl stacked on top of each other so we don't take up so much horizontal space. Right now we take up 2 lines of text with wrapping of the test name, this would take up 3 lines of text.

Using Flask (http://flask.pocoo.org/) rather than wsgiref.simple_server in server.py will remove boilerplate code and make it easier to serve static content when running standalone.

it would be great to search by test name as well, 2 ways:

1. url param: &testname=tp5o
2. drop down selection in the search field- this wouuld be a static div at the top of the page with the current test selected and when a new one is selected we would reload the page with the new filtered tests.

this should work in conjunction with other parameters:
&rev=xyz&platform=linux64&testname=tp5o

Currently view and Hide merged alerts is implemented in such a way that if you click on hide merge alerts after viewing them it does not hide and if again you click on view alerts it shows them again thus creating multiple copies as you keep on repeating the process

when there is no bug, we have a link 'add bug #', that when you click it an add bug form is popped up to enter a bug. Once this is done, there is no way to change that.

Sometimes we close a bug as a duplicate and it would be nice to make this easier to change. One thought is a little + sign next to the bug number (hyperlink) which would pop open the add bug form.

we can use the public data and hack on the UI easily- but if we want to work on the server or parsing, we need raw data or a workable server.

We should create a docker image/script so we can setup the webserver, config, database, clone the repo, and test that we can get http://localhost/data/alertsbyrev to print out some data.

we should include some sample data as well :)

many times we find a regression that is for a specific revision. unfortunately we don't have data for changesets prior, sometimes 3 or 4 changesets.

There are 2 things to sort out here:

1. we didn't do the platform build
2. we did the build, but didn't run the perf test

For item #1, we don't build desktop builds for android only (*.java) changes. Likewise some b2g specific changes or test-only changes.

This is why I don't want it to be automatic, but I would like to have a one click button to bring me to a way to launch a build if it is missing. If we do a build, most likely we will run the talos test that was missing. Also in this case we need to context switch out for 3-5 hours until the build is done (pgo takes even longer).

For item #2, we can easily trigger the talos job that wasn't run.

Lastly to reduce the effect of noise, I always do 3 retriggers of each job (2 prior, the suspect changeset, 1 after).

Here is a reference to the arbitrary build scheduler:
http://johnzeller.com/blog/2014/03/12/triggering-of-arbitrary-buildstests-is-now-possible/

Ideally this would be a single click button so we could sanity check we are doing the right thing before scheduling a bunch of jobs.

an example is this-

we generate: