I am not sure if this will require changes in the resultsdb app or not. Currently we only have one user (openqa) and I am not sure if it's setup for multiple users, but it might be! :)

Ahh, I thought Fedora CI was also submitting results to ResultsDB? Or do you mean they're both currently using the same openqa creds?

I'm fine with whatever SOP is currently in place (i.e. if that's to use the same user for now). Just looking to submit some test results. :)

It is, but the way it submits is to emit fedora-messaging messages and 'resultsdb-ci-listener' inserts those directly to the db.

openqa posts them to a http endpoint with username/pass.

So, I suppose if you wanted you could look at just emitting messages and we could look at expanding resultsdb-ci-listener to record them?

So, I suppose if you wanted you could look at just emitting messages and we could look at expanding resultsdb-ci-listener to record them?

I have a preference for doing this via HTTP because it's much less heavyweight, but I'm OK with messaging too. (Though I think that would require some rework of what I currently have and probably stop using @adamwill's https://pagure.io/taskotron/resultsdb_conventions and re-implement some of the "convention" bits manually).

resultsdb-ci-listener is a bit problematic, to be honest - it already does not forward some results it should because it only understands a limited set of expected message formats. I've got 'fix that thing up' somewhere buried on my todo list, but it's not going to happen any time soon unless I quixotically feel like it one day, and I don't know if it's on anyone else's list. It definitely would not be able to understand the messages FCOS will want to publish ATM, because they want to test updates, and it's basically hardcoded to expect messages for tests of packages - it just won't handle messages for tests of composes or updates. See https://pagure.io/ci-resultsdb-listener/blob/master/f/resultsdb_listener/consumer.py .

we could, potentially, just let it use the same user openqa is using. That username and password is already shared by openQA's reporter and resultsdb-ci-listener itself: note that prod_resultsdb_httpd_password is referenced in both inventory/group_vars/openqa and roles/openshift-apps/resultsdb-ci-listener/templates/secrets.yml. I just wasn't sure if we were OK with that (since it would mean trusting something outside of fedora infra ansible to keep that password secret, I guess) or would rather have a new user/password.

when I talked to @mvadkert about this a while back we kinda agreed in principle that we should probably just get rid of resultsdb-ci-listener entirely and have CI file results directly into resultsdb. In theory this is the more sensible design because resultsdb already publishes a message whenever a result is submitted. So it seems kinda silly to do this (what CI currently does):

test system -> message -> listener -> resultsdb -> another message

or even this (which is what openQA currently does):

test system -> message
test system -> resultsdb -> another message

when we could just do:

test system -> resultsdb -> message

and anything that wants to consume a message can just consume the messages resultsdb publishes. But that's not a high priority for anyone either, sigh.

Yeah, I'm perfectly fine with killing resultsdb-ci-listener off...

We just need to make sure we can specify multiple users for the http endpoint. I think I would prefer them to be seperate if we can manage it.

So now that GA is out the door, how can I help make progress on this? :) Is there a ResultsDB SME we can reach out to to get more info on authentication?

ok. I looked at this again and it turns out it should be trivial to do. ;)

Whats the best way to get you the username/passwords? I can put them in a file in your homedir on batcave01? Or gpg encrypt them to you? or bitwarden send (which I haven't used, but have heard of). ;)

ok. I looked at this again and it turns out it should be trivial to do. ;)

Sweet! :tada:

Whats the best way to get you the username/passwords? I can put them in a file in your homedir on batcave01? Or gpg encrypt them to you? or bitwarden send (which I haven't used, but have heard of). ;)

Email with GPG encrypted creds would be my preferred way. Thanks!

https://jlebon.fedorapeople.org/pubkey.gpg.asc

ok, user created, creds encrypted and mailed.

Note that I haven't tested, but if you hit any problems with it, please let us know! :)

Tested working on both stg and prod. Thanks!

ooo. nice! and through the magic of science, we see the result on the Automated Tests tab of the update. it's nice when things work

Awesome. :thumbsup: