resultsdbProject
ActivePublic

Watchers

  • This project does not have any watchers.

Properties

Description

database and frontend for results storage

Recent Activity

Wed, Jul 19

Diffusion closed D1108: Add OpenID Connect auth module for POST requests by committing rRSDBa8cd18abfc92: Add OpenID Connect auth module for POST requests (authored by Patrick Uiterwijk <puiterwi@redhat.com>).
Wed, Jul 19, 4:40 PM · resultsdb
puiterwijk updated the diff for D1108: Add OpenID Connect auth module for POST requests.
Wed, Jul 19, 12:09 PM · resultsdb
puiterwijk updated the diff for D1108: Add OpenID Connect auth module for POST requests.

Now making more use of the flask-oidc 1.1 features to do less token checking inside resultsdb itself.

Wed, Jul 19, 11:13 AM · resultsdb

Thu, Jul 13

mkrizek resigned from D1108: Add OpenID Connect auth module for POST requests.
Thu, Jul 13, 9:03 AM · resultsdb

Mon, Jul 3

mjia added a comment to T960: publish ResultsDB package to PyPI.

I do not think we should sync requirements.txt into setup.py. We only need some of the packages in the requirements.txt, not all of them.
Also, it is not a best pratice to pin dependencies to specific versions for install_requires. I would rather do something like this
install_requires=[

'fedmsg',
'alembic'
...

]

Mon, Jul 3, 1:44 AM · resultsdb

Sun, Jul 2

mjia added a comment to T960: publish ResultsDB package to PyPI.

@jskladan , we're expecting the developers to set up a development enviroment with pip in a python virtualenv[1]. What we want is to be able to do this[2] when ResultsDB is installed with pip.
I will commit some time to sumibt a patch.

Sun, Jul 2, 11:34 PM · resultsdb

Fri, Jun 30

jskladan added a comment to T960: publish ResultsDB package to PyPI.

for future ref, the reasonable way to get around syncing requirements.txt and setup.py is adding:

+ with open('requirements.txt') as fd:
+     install_requires = [l.strip() for l in fd.readlines() if l.strip() and not l.strip().startswith('#>
...
+       install_requires=install_requires,

to setup.py

Fri, Jun 30, 2:33 PM · resultsdb
jskladan lowered the priority of T960: publish ResultsDB package to PyPI from "Low" to "Wishlist".

@mjia BTW what exactly is your use-case, and why is installing from repos not OK for you? I'm asking for two reasons

  1. packaging resultsdb for PyPi is proving to be rather a PITA
  2. if you actually need to use resultsdb, setup is necessary - like creating the database, for example - since you are going to need to solve this too (probably are right now anyway) is installing from repos (aka another line in that script that you'll have to have to setup resultsdb anyway) a problem?
Fri, Jun 30, 2:26 PM · resultsdb
jskladan raised the priority of T960: publish ResultsDB package to PyPI from "Wishlist" to "Low".

Hi, @mija, I don't have any fundamental issues with it, apart of the fact that it adds yet another place to store/track deps.

Fri, Jun 30, 1:35 PM · resultsdb
kparal triaged T960: publish ResultsDB package to PyPI as "Wishlist" priority.
Fri, Jun 30, 1:23 PM · resultsdb
kparal added a revision to T961: Flask-RESTful==0.3.6 breaks unit tests: D1217: requirements: limit Flask-RESTful to <= 0.3.5.
Fri, Jun 30, 1:00 PM · resultsdb
kparal added a comment to T961: Flask-RESTful==0.3.6 breaks unit tests.

You can see the error log in F99608.

Fri, Jun 30, 12:56 PM · resultsdb
kparal renamed T961: Flask-RESTful==0.3.6 breaks unit tests from "Tests failing with the environment in requirements.txt" to "Flask-RESTful==0.3.6 breaks unit tests".
Fri, Jun 30, 12:53 PM · resultsdb
kparal triaged T961: Flask-RESTful==0.3.6 breaks unit tests as "High" priority.

The problem is in Flask-RESTful==0.3.6. If you use <= 0.3.5, everything works for me. I'll prepare a patch to restrict the max version number. And somebody should figure out why that happens and whether it's something that we need to fix in our tests, or whether it's a flask-restful bug.

Fri, Jun 30, 12:53 PM · resultsdb

Sun, Jun 25

yashn created T961: Flask-RESTful==0.3.6 breaks unit tests.
Sun, Jun 25, 5:05 PM · resultsdb
mjia created T960: publish ResultsDB package to PyPI.
Sun, Jun 25, 5:05 PM · resultsdb

Jun 5 2017

kparal closed T956: testcases wildcarded query crashes as "Invalid".

Doh, again I forgot the difference between API endpoint and our frontend.
https://taskotron.fedoraproject.org/resultsdb_api//api/v2.0/testcases?name:like=dist.modulemd*

Jun 5 2017, 11:18 AM · resultsdb
kparal created T956: testcases wildcarded query crashes.
Jun 5 2017, 11:17 AM · resultsdb

Apr 11 2017

kparal created T937: resultsdb_frontend crashes when /latest endpoint is used.
Apr 11 2017, 12:56 PM · resultsdb

Mar 21 2017

kparal lowered the priority of T929: production resultsdb fails to run from "Unbreak Now!" to "High".

Production resultsdb seems to work better now, so lowering the priority. However, since we can't track how many tasks failed to post results (since we don't fail them if they do so), it's hard to guess how much uptime do we actually have. Maybe we should start failing jobs if resultsdb responds 5xx? Or retry a few times and fail eventually?

Mar 21 2017, 11:07 AM · Restricted Project, resultsdb, infrastructure

Mar 17 2017

kparal added a comment to T929: production resultsdb fails to run.

Googlebot stopped hammering us, new robots.txt work. They are present in ansible now. However, it didn't solve the problems, resultsdb (and execdb) is down again.

Mar 17 2017, 7:25 AM · Restricted Project, resultsdb, infrastructure

Mar 16 2017

kparal added a comment to T929: production resultsdb fails to run.

I have deployed new robots.txt: https://taskotron.fedoraproject.org/robots.txt
We should see whether it helps in a day or so (once Google refreshes that file). Btw, these are the current per-hour access numbers from Google:
2568
2341
3083
4336
3213
4225
3738
So about 3300 hits per hour on overage, 55 per minute. They are performed in bursts, though (ten or twenty simultaneous requests, then a pause, then again).

Mar 16 2017, 1:12 PM · Restricted Project, resultsdb, infrastructure
kparal added a comment to T929: production resultsdb fails to run.

Today resultsdb_api seems to run somewhat (testcases work, but some tasks fail to post results). The frontend seems completely non-functional (testcases return Service Unavailable).

Mar 16 2017, 9:09 AM · Restricted Project, resultsdb, infrastructure

Mar 15 2017

tflink added a comment to T929: production resultsdb fails to run.

A short term patch could be to increase the number of processes allocated to the wsgi application.

Mar 15 2017, 12:09 PM · Restricted Project, resultsdb, infrastructure
kparal moved T929: production resultsdb fails to run from Restricted Project Column to Restricted Project Column on the Restricted Project board.
Mar 15 2017, 10:07 AM · Restricted Project, resultsdb, infrastructure
kparal created T929: production resultsdb fails to run.
Mar 15 2017, 10:07 AM · Restricted Project, resultsdb, infrastructure

Mar 13 2017

kparal set the repository for D1108: Add OpenID Connect auth module for POST requests to rRSDB resultsdb.
Mar 13 2017, 3:51 PM · resultsdb

Feb 27 2017

kparal placed T716: Write Docs for Reporting and Namespaces up for grabs.

I think this changed quite a bit with the inception of resultsdb_conventions. Any working on this should probably study that project first.

Feb 27 2017, 8:08 PM · Restricted Project, libtaskotron, resultsdb

Feb 21 2017

kparal closed T890: resultsdb_frontend: search is completely broken in production as "Resolved".

@mkrizek deployed the new updates. Seems to be working. Closing.

Feb 21 2017, 1:59 PM · Restricted Project, resultsdb

Feb 20 2017

kparal added a comment to T890: resultsdb_frontend: search is completely broken in production.

I submitted the new packages to stable. I assume we'll update it on prod tomorrow, and if nothing breaks, I'll close this.

Feb 20 2017, 2:29 PM · Restricted Project, resultsdb
jskladan added a comment to T890: resultsdb_frontend: search is completely broken in production.

Are there issues, still, or are we waiting for the changes to be deployed on all the instances? Dev seems to be working reasonably well for me.

Feb 20 2017, 2:16 PM · Restricted Project, resultsdb
kparal moved T890: resultsdb_frontend: search is completely broken in production from Restricted Project Column to Restricted Project Column on the Restricted Project board.
Feb 20 2017, 12:25 PM · Restricted Project, resultsdb

Feb 15 2017

adamwill created T907: Make resultsdb_api Python 3 compatible.
Feb 15 2017, 10:55 PM · resultsdb

Feb 10 2017

jskladan added a comment to T904: Taskotron creates huge numbers of ResultsDB groups with duplicate names.

@adamwill absolutely just a courtesy - we are still talking conventions (like "you should provide an item" style convention, maybe, but still a convention), not hard rules, at least in the scope of the actual implementation.
Also, even if this was "the true way", I'd still see a reason to have "I don't care, and just want a random UUID" thing, and the UUID is also a nice identifier, as it has constant length and such things that only really matter for the machines, and humans don't care, but are important anyway.
Good thing about the actual implementation is, that there won't be collisions between the "random" and "specific" UUIDs by definition of how UUIDs work (different namespaces), so you don't even need to be concerned about "random group results" mixing up with the "proper" ones.

Feb 10 2017, 6:27 AM · resultsdb, libtaskotron
adamwill added a comment to T904: Taskotron creates huge numbers of ResultsDB groups with duplicate names.

Sure, it makes sense to me. I guess the only question is, does this become the One True Way of creating and identifying groups in resultsdb, or is it merely a courtesy feature in the resultsdb core for the benefit of things that respect this particular convention for naming groups and creating group UUIDs?

Feb 10 2017, 2:09 AM · resultsdb, libtaskotron

Feb 8 2017

jskladan added a comment to T904: Taskotron creates huge numbers of ResultsDB groups with duplicate names.

If we're only considering factors like 'not-important-enough-tests', 'dupes' and 'mistakes', I don't think we need to worry about how 'secure' group names or extradata values are. My initial inclination is not to worry about it unless it actually becomes a problem.

Feb 8 2017, 11:38 PM · resultsdb, libtaskotron
adamwill added a comment to T904: Taskotron creates huge numbers of ResultsDB groups with duplicate names.

Well, not a 'problem', no, not exactly. I mean, it's actually one of the things resultsdb_conventions is *specifically intended to achieve*: it allows (almost requires) different systems to report results to at least some of the same group(s). It establishes the convention 'all test results for a compose should go into a group named for that compose', and *any* reporter that buys into the conventions 'system' and uses the 'compose' convention (or a child of it) will put its results into that group. It's really almost the opposite of what you're talking about: conventions is explicitly a system for *enabling* different systems/submitters to collate / relate related results (in groups, and also by having similarly formatted extradata). Further, at least in my head, the conventions aren't tied to resultsdb_conventions-the-codebase, that's just a current implementation detail; it seems entirely reasonable to me that someone might build another submitter that doesn't actually use resultsdb_conventions (write it in Go or whatever you like), but does respect the same *conventions*.

Feb 8 2017, 8:01 PM · resultsdb, libtaskotron
kparal added a comment to T904: Taskotron creates huge numbers of ResultsDB groups with duplicate names.

I understand now why you want to be able to query by group name, have them unique, and use consistent and predictable naming. And it makes sense. Originally we never imagined such use case, I believe, and simply used it to group results from a single task run together (which is sometimes useful when a human inspects the results, that's all). And waited for more use cases (Josef, correct me if I'm wrong). The way you want to use groups is exactly such a new use case, and I would personally probably have solved it with extradata, if I hadn't read this. But using groups can be a better way to tackle this, and maybe even less demanding on the database (Josef?).

Feb 8 2017, 7:45 PM · resultsdb, libtaskotron
kparal added a project to T904: Taskotron creates huge numbers of ResultsDB groups with duplicate names: resultsdb.
Feb 8 2017, 1:30 PM · resultsdb, libtaskotron

Feb 6 2017

adamwill added a comment to T892: Update and enable openQA result reporting to ResultsDB.

I was going to have it done already, but couldn't while my web server was down. I'll write one today or tomorrow.

Feb 6 2017, 11:53 PM · resultsdb, fedora_openqa

Feb 3 2017

kparal updated subscribers of T892: Update and enable openQA result reporting to ResultsDB.

We need a blogpost about this new awesome feature! I see 4 volunteers:
@adamwill
@jsedlak
@garretraziel
@garretraziel_but_actually_jsedlak_who_uses_stupid_nicknames
I don't really care who does it, we can even pick randomly!

Feb 3 2017, 10:30 AM · resultsdb, fedora_openqa
kparal added a comment to T900: resultsdb_api: test suite is failing.

Once this is fixed, please also enable automatic test suite execution in Phab, so that we don't encounter this again in the future. See D1113 to learn how.

Feb 3 2017, 9:38 AM · resultsdb

Feb 2 2017

adamwill closed T892: Update and enable openQA result reporting to ResultsDB as "Resolved".
Feb 2 2017, 5:09 PM · resultsdb, fedora_openqa
adamwill updated subscribers of T892: Update and enable openQA result reporting to ResultsDB.

Done, shipped, let's go drink beer. @jsedlak did most of the work in D1102 and D1109 , I twiddled a couple of bits and wrote a fedmsg consumer.

Feb 2 2017, 5:06 PM · resultsdb, fedora_openqa
kparal closed T901: latest resultsdb build can't upgrade db as "Resolved".

Should be fixed in d39eadc6f8435e2d9.

Feb 2 2017, 4:39 PM · resultsdb
kparal claimed T901: latest resultsdb build can't upgrade db.
Feb 2 2017, 4:32 PM · resultsdb
tflink created T901: latest resultsdb build can't upgrade db.
Feb 2 2017, 4:02 PM · resultsdb
kparal closed T897: Sync up versions of resultsdb/frontend/api and build rpms from what's in develop as "Resolved".

Fixed in db96c6e21cf865038e , 864c63a4ad3e0e5aa7 and eb561f2aaa72e5717c9c8e3.

Feb 2 2017, 3:53 PM · resultsdb, infrastructure
kparal added a revision to T883: first submission to resultsdb fails: KeyError: "'dummy' not found in []": D1111: Makefile: fix `make test`.
Feb 2 2017, 3:46 PM · resultsdb
jskladan claimed T900: resultsdb_api: test suite is failing.
Feb 2 2017, 12:14 PM · resultsdb