https://pagure.io/fedora-infra/ansible/pull-request/116

Note that we are waiting for an upstream to be set up and working before we change things so that we do not fork/break their work.

@smooge hi, this is a major user annoyance, could we make this work pls?

The change here should be just a change in configuration, we use it in downstream for years.

This is blocked on https://pagure.io/fedora-infrastructure/issue/8415

@kevin @pingou Are there any updates on this?

I don't think it is reasonable to block a one-line fix on the ownership question for such a long time.

Can we please apply the change, while having the conversation in parallel?

@bookwar unfortunately CPE are not in a position to merge this, we have no ownership over the code and our role in CPE is simply to run the service and keep it alive. We want to actively avoid "the last one who touches it owns it" as well as the "you've done it last time you can do it again" scenarios that will come from this. I'd suggest two things:

• Ping the actual maintainers here or raise them in a mail thread and ask them to approve / merge or seek approval to have yourself granted such permissions to solve this in the short term
• Bring more focus to the 8415 issue above to find a longer term solution to this. I have engaged with several people on this but it has not progressed in 7 months.

I hope you understand the difficult position we are in and respect the stance that we have to make on this.

There is no code change in the proposed pull request. We are asking to change the configuration of the deployed instance of the service.

I understand your point on splitting responsibilities, but I think the current situation is different.

We prepared and proposed a patch for ansible playbooks of Fedora Infrastructure to change the configuration option of a running service. I don't see why upstream maintainers need to be involved in this decision.

(I think you tagged the wrong person above)

Our team have indicated that we require a +1 from the maintainer before merging anything like this, even if it is just a configuration change, we need that level of support and approval. Until we get that approval we are not in a position to merge.

Removing the "dev" tag from this ticket as there is nothing to develop. This issue is still blocked on https://pagure.io/fedora-infrastructure/issue/8415

This should be fixed once we migrate resultsdb to openshift.

super cool :fireworks:

This seems like a bit of a hack, to me, honestly. "queued" and "running" are not outcomes. They are not results. They are execution states.

ResultsDB is/was supposed to be, as the same says, a database for storing test results. It doesn't seem ideal to make it something else just for the sake of convenience for a specific usage pattern.

Taskotron previously had a thing called ExecDB which was, as you'd expect, for storing test execution states. IIRC it got taken out in a rewrite at some point, but the concept was there.

As things stand I can query resultsdb and be confident that the things I get back are actual test results. If we change this I now need to somehow know that certain outcomes aren't results at all. And because resultsdb is intended to be simple, there isn't even really some standard API or library where this could be documented and explained. It would just become weird magic knowledge.

Yeah, it is a hack but also long hanging fruit to give users idea about their test is running. Currently the end user experience is fairly bad, users have no idea that the test is running. We are using this in downstream for several years now. But it is true, there we have CI dashboard :( I personally do not mind another solution to the problem, but would like to avoid another year of delay to get something working out.

yeah, that's a fair point. I wonder how much work it would be just to deploy another instance of resultsdb but brand it as 'execdb' or 'statedb'. initially it could just be the url that differs, we could always patch strings in the code itself to be configurable later.

edit: other options:

1. just rebrand single-instance resultsdb itself
2. tell things that want to know about state there isn't a db, they have to listen for messages

CPE will not be hosting an additional service like this. I understand the sentiment and separation of concerns, but this becomes another thing to maintain when there are better solutions to pursue.

Well, the low hanging fruit is just to add that one configuration line to resultsdb :) and update the ingester to react on queued/running msgs. This is what we have on downstream. We need to make sure this does not break any QE / Devel / Random workflow that is using resultsdb. Greenwave can already cope with it I believe.

So, @lrossetti has gotten resultsdb running in openshift. After the freeze is over we need to migrate to that openshift version from the standalone one.

[backlog refinement]

This is dependant on the work being done to get resultsdb to openshift which is getting close in stg

This should be up and running in stg now... :)

https://resultsdb.stg.fedoraproject.org/results

@kevin thank you! looks good, can we move it to production pretty please?

This is now in production. ;)