infra/tickets

Fork 1

tmt virtual provision broken because of oraculum not working #13390

New issue

Closed

opened 2026-06-04 10:43:44 +00:00 by psss · 6 comments

psss commented

2026-06-04 10:43:44 +00:00

Description of request

Seems that oraculum is not working. This breaks virtual provision plugin in tmt. Steps to reproduce:

> tmt run provision --how virtual
/var/tmp/tmt/run-009

/default/plan
    provision
        queued provision.provision tasks
            #1: default-0
        
        provision.provision task #1: default-0
        how: virtual
        ansible: {}

Couldn't fetch Fedora releases from oraculum...
        fail: 
Couldn't fetch Fedora releases from oraculum...
        fail: 
Couldn't fetch Fedora releases from oraculum...
        fail:

This is currently blocking the tmt-1.75 release.

Related: apps/oraculum#223

### Description of request Seems that oraculum is not working. This breaks `virtual` provision plugin in `tmt`. Steps to reproduce: ``` > tmt run provision --how virtual /var/tmp/tmt/run-009 /default/plan provision queued provision.provision tasks #1: default-0 provision.provision task #1: default-0 how: virtual ansible: {} Couldn't fetch Fedora releases from oraculum... fail: Couldn't fetch Fedora releases from oraculum... fail: Couldn't fetch Fedora releases from oraculum... fail: ``` This is currently blocking the `tmt-1.75` release. Related: https://forge.fedoraproject.org/apps/oraculum/issues/223

zlopez added the

day-to-day

points

labels

2026-06-04 10:48:41 +00:00

zlopez self-assigned this

2026-06-04 10:48:52 +00:00

psss commented

2026-06-04 10:49:00 +00:00

Author

Related snipped from the testcloud code:

    try:
        oraculum_releases = session.get("https://packager-dashboard.fedoraproject.org/api/v1/releases").json()
    except (ConnectionError, IndexError, requests.exceptions.JSONDecodeError):
        log.error("Couldn't fetch Fedora releases from oraculum...")
        raise exceptions.TestcloudImageError

The url is not working:

https://packager-dashboard.fedoraproject.org/api/v1/releases

Related snipped from the `testcloud` [code](https://github.com/teemtee/testcloud/blob/main/testcloud/distro_utils/fedora.py): ```python try: oraculum_releases = session.get("https://packager-dashboard.fedoraproject.org/api/v1/releases").json() except (ConnectionError, IndexError, requests.exceptions.JSONDecodeError): log.error("Couldn't fetch Fedora releases from oraculum...") raise exceptions.TestcloudImageError ``` The url is not working: * https://packager-dashboard.fedoraproject.org/api/v1/releases

psss referenced this issue from apps/oraculum

2026-06-04 10:50:30 +00:00

tmt virtual provision broken because of oraculum not working #223

zlopez commented

2026-06-04 10:52:47 +00:00

Owner

I'm already working on this, the issue is caused by redis deployment, which was updated 2 days ago and started failing on permission issue, which is reported here. I tried to revert to previous redis container version, but it's failing on docker ratelimit, which is reset every 6 hours.

I currently thinking of building fedora based container for redis for oraculum to just not be blocked by docker.io in the future.

I'm already working on this, the issue is caused by redis deployment, which was updated 2 days ago and started failing on permission issue, which is reported [here](https://github.com/bitnami/containers/issues/94146). I tried to revert to previous redis container version, but it's failing on [docker ratelimit](https://docs.docker.com/docker-hub/usage/), which is reset every 6 hours. I currently thinking of building fedora based container for redis for oraculum to just not be blocked by docker.io in the future.

zlopez referenced this issue from a commit

2026-06-04 11:14:43 +00:00

[oraculum] Build the redis container locally

zlopez referenced this issue from infra/ansible

2026-06-04 11:15:52 +00:00

[oraculum] Build the redis container locally #3391

zlopez commented

2026-06-04 11:29:47 +00:00

Owner

So I used the flatpak-indexer build of redis based on Fedora.
The changes could be found in these two ansible commits:

And the oraculum is running again.

So I used the flatpak-indexer build of redis based on Fedora. The changes could be found in these two ansible commits: * https://forge.fedoraproject.org/infra/ansible/pulls/3391 * https://forge.fedoraproject.org/infra/ansible/pulls/3392 And the oraculum is running again.

zlopez commented

2026-06-04 11:53:02 +00:00

Owner

I got confirmed that this is working now for Fedora QE. Closing the ticket.

zlopez closed this issue

2026-06-04 11:53:02 +00:00

zlopez added this to the Current Sprint ( 2026-06-01 to 2026-06-14) project

2026-06-04 11:53:09 +00:00

zlopez added

points

and removed

points

labels

2026-06-04 11:59:56 +00:00

kevin commented

2026-06-04 17:33:37 +00:00

Owner

You may want to consider using bodhi for this information? (but it has it's own tradeoffs I suppose).

adamwill commented

2026-06-04 17:40:39 +00:00

Member

I believe currently that info ultimately comes from fedfind, see here. fedfind itself sources the info from https://fedorapeople.org/groups/qa/metadata/release.json which we update by hand, so there's kinda a lot of moving parts to turn one JSON file into another there :D But it's probably okay.

The difference between fedfind and Bodhi as a source of truth here is more or less that we mark releases as stable in the fedfind metadata later. We flip the release to 'current' in Bodhi shortly after the Go decision. We move the release to 'stable' in the fedfind metadata only on public release day. So if you have a specific preference for either point in your code, that determines the source-of-truth you should pick. If it doesn't much matter, pick either. I would previously have said Bodhi is somewhat more likely to be promptly updated if you don't have a preference, but we've updated a lot of SOPs lately to say "...and update the fedfind metadata!" so it should get updated pretty reliably now.

I believe currently that info ultimately comes from fedfind, see [here](https://forge.fedoraproject.org/apps/oraculum/src/commit/fb7c097a43b01caf214971bc299f3f2ddb08fd2c/oraculum/utils/dashboard_helpers.py#L185-L189). fedfind itself sources the info from https://fedorapeople.org/groups/qa/metadata/release.json which we update by hand, so there's kinda a lot of moving parts to turn one JSON file into another there :D But it's probably okay. The difference between fedfind and Bodhi as a source of truth here is more or less that we mark releases as stable in the fedfind metadata later. We flip the release to 'current' in Bodhi shortly after the Go decision. We move the release to 'stable' in the fedfind metadata only on public release day. So if you have a specific preference for either point in your code, that determines the source-of-truth you should pick. If it doesn't much matter, pick either. I would previously have said Bodhi is somewhat more likely to be promptly updated if you don't have a preference, but we've updated a lot of SOPs lately to say "...and update the fedfind metadata!" so it *should* get updated pretty reliably now.