#9464 move resultsdb off fedora-31
Opened 3 months ago by kevin. Modified 2 days ago

Fedora 31 goes EOL soon. We need to move resultsdb01 and resultsdb01.stg off it to something else.

We could move them to f33, or el8. Should investigate what runs on them and if it's easily available in el8.


I've raised this with management a few days ago. Technically we can do the migration, but it would be nice to know to which OS we should migrate, so I'm trying to find who can give us that answer

Metadata Update from @pingou:
- Issue assigned to pingou

3 months ago

Metadata Update from @humaton:
- Issue tagged with: medium-gain, medium-trouble, ops

3 months ago

Metadata Update from @smooge:
- Issue priority set to: Waiting on Assignee (was: Needs Review)

3 months ago

Metadata Update from @asaleh:
- Issue priority set to: Waiting on External (was: Waiting on Assignee)

a month ago

We probably need to ask Leigh, if this is our responsibility and agree on the resultsdb owner

We probably need to ask Leigh, if this is our responsibility and agree on the resultsdb owner

This conversation has been going on for over a year at this point I think. We're trying to reduce the number of applications we maintain, so we do not want to take on resultsdb.

I have raised this again for resolution, this is outside of our control.

Maybe we would need to agree on a sort of a minimal responsibility from our side? Ee are responsible for Bodhi (and its gating feature depends on resultsdb) and we are running resultsdb on our infrastructure.

One reasonable stance could be "We are responsible for running the resultsdb service on our infrastructure to support Fedora QA, we are not responsible for development, and bug fixes." and as far as I looked into our ansible repo and at the public resultsdb source, that seems to be the current de-facto state?

This is what we are trying to get agreement on, we will run it, submit PRs, review and help where we can but we don't have the authority to merge code as this is an upstream/downstream relationship and we ultimately don't want to own that code.

And have a way/person/group to reach out to in case we encounter issues with it that we cannot solve.

Any news here? How long do we want to keep running this in a limbo state?

Any news here? How long do we want to keep running this in a limbo state?

AFAIK it's still being discussed, it's moving, just slowly.

@lgriffin do you agree?

I should have a firm direction on this next week, stay tuned

Login to comment on this ticket.

Metadata
Boards 1
ops Status: Blocked