gluster / fstat Goto Github PK

Each failure needs a column with a link to the review request.

It's good to show 12 weeks of data so we can compare between release cycles.

Currently fstat only captures the stats of particular test failures. However there are instances where some of the regression runs get aborted due to a genuine bug in the code. It'd be really helpful if this stat can be captured in the report too.

The final ask (for now) is to possibly look at a column or separation around job. This is useful to understand what failed with mux vs non-mux (for starters) and once we can list by jobs, or add job based columns it may become easier.

It'll be easier on the eyes to locate a job type in bold, probably as the title of the table, followed by the table mentioning only the node and the time-stamp.

Thinking about it further, a page per job type would be good too.
So, you could show the break-up of the different jobs and the count against the job in the main page, which would then take the user to the job specific page.
eg. the main page would look like

Signature                                      Failure count
./tests/basic/gfapi/gfapi-async-calls-test.t   centos6-regression:14, netbsd7-regression:11

We use relative dates right now when we say "failures in the last 1 week". Instead use the dates from the last Monday until the Sunday afterward.

This means the URLs can be idempotent and will always show the same information, especially when looking at history. We'll be able to predict increase/decrease better this way.

https://github.com/gluster/fstat/blob/master/fstat/templates/index.html#L62

Instead of {{ signature }}, it probably should say {{ failure['signature'] }}

Let's start with the ability to login so we move from a read-only to website to having the capability for the right people to write to the website.

When build.gluster.org API doesn't respond, we throw a traceback rather than catching it gracefully.

Sentry Issue: FSTAT-4

ValueError: No JSON object could be decoded
(5 additional frame(s) were not displayed)
...
  File "parser.py", line 95, in get_summary
    ]), verify=False).json()
  File "models.py", line 896, in json
    return complexjson.loads(self.text, **kwargs)
  File "__init__.py", line 338, in loads
    return _default_decoder.decode(s)
  File "decoder.py", line 366, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "decoder.py", line 384, in raw_decode
    raise ValueError("No JSON object could be decoded")

If the period of the 7 days which is being tracked can be mentioned. As an example, for a page that is loaded today, a "until 07Nov" enables the viewer to understand that the numbers go back an actual calendar week. It would also aid in understanding if any activity during the week contributed to the spike/trough of the failures.

We show Monday to current day. Looking at it on Monday shows no results. We should probably do previous Monday to today when looking at the summary page on a Monday.

It should probably just show username and a log out button.

Sentry Issue: FSTAT-5

ValueError: unconverted data remains: 'A=0
(3 additional frame(s) were not displayed)
...
  File "app.py", line 1813, in full_dispatch_request
    rv = self.dispatch_request()
  File "app.py", line 1799, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "controller.py", line 146, in instance_summary
    start_date = parse_start_date(request.args.get('start_date'))
  File "lib.py", line 27, in parse_start_date
    start_date = datetime.strptime(start_date, '%Y-%m-%d')
  File "_strptime.py", line 328, in _strptime
    data_string[found.end():])

It's a centos job that's run every 4 hours. It runs against the HEAD of the master at that moment in time. This is useful to catch intermittent failures that are definitely not caused by a particular change.

This way we can track a failure as a known issue and track the bug to completion. We probably want many <-> many between bugs and failures.

Create the ability to filter by branch for hunting regressions that affect only on branch.

fstat regex was not written with timeout failures in mind. So if a test fails due to timeout, we won't catch it.

The data being collected and organized by fstat can be used to generate trends and presented to public. Perhaps this is a function of designing end-points for the data store and hence marked as 'Future' and possibly a '3rd party application' to fstat

It always resets the dates, so I could not select properly the from and to.
Workaround: manually entering the dates worked.

We need to start capturing failures from line coverage tests.