#9371 debuginfod service
Opened 21 days ago by fche. Modified 13 days ago

Describe what you would like us to do:

Let's get an elfutils-debuginfod server up and running for the public fedora community. This will let developers/users fully debug/trace fedora software without have to do #sudo yum commands.

fedora-devel thread: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/K54HO3X7ANUBFN4OQCQ4QBOYSR4HTSR5/
upstream project: https://sourceware.org/elfutils/Debuginfod.html

Last year, in issue #7943, y'all kindly let us develop/test the software against the giant koji build archive. (In case that VM has survived the fedora move, please feel free to release its resources.) Our team has operated a public-facing internet service for some time since, and the software seems to be reasonably stable and useful.

There are a bunch of issues to talk through with your team, if y'all are interested, with regards to resources & security & approach. Should I summarize them in writing here, or at some meeting verbally? We would be pleased to install / operate / maintain the server, given koji-proximate resources & access.

The gist of it: a server instance is unprivileged; takes barely any CPU (except when on-the-fly decompressing large RPMs), say ~16GB RAM, an index sqlite db of ~3% of the storage used by the RPM files it is configured to serve; is easily partitioned by architecture or other filename-regex expressible properties; is replicable; its own data is disposable (the index is a cache); the index db could be shared across instances;

When do you need this to be done by? (YYYY/MM/DD)

No rush.

We decided to consider this as an initiative, pinging @amoloney @lgriffin to start the initiatives process.

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

21 days ago

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

20 days ago

Considering the outcome of the discussion on the devel list. What do we want to do about this ticket?

If it's worth doing then as suggested, it is likely worth of an initiative and thus should be discussed with @amoloney.

Otherwise, should we close this ticket?

I got the instructions on how to make an initiative and am working with the requester on that. I would like to keep this ticket open for at least one more week as it is what is referred to in the initial documents and it isn't clear if the process will push it back to this.

We also may want to hear back from @fche if they want to look at just adding this on to the existing retrace/faf server. If they go that way it could largely be handled by that team.

@kevin, we're going to talk with the retrace/faf folks early next week to see if there is an opportunity to share hardware for example.

Checking in with news that we did talk with @msuchy of the retrace/faf folks. Brief findings:

  • there is no direct overlap at the user-facing side
    • abrtd produces backtrace reports from coredumps
    • debuginfod produces debuginfo/source files from buildids
  • there is some overlap at the backend side:
    • debuginfod consumes fedora/centos rpms
    • abrtd consumes (cron-downloaded) fedora/centos rpms
  • there is some opportunity for interoperation
    • abrtd could become a debuginfod client, because it just really needs that info, not all the rpms
    • debuginfod could scrape rpms from the fedora-abrt rpm cache
      • if those files were named conveniently (retaining dir/dir/file.rpm naming somehow, rather than opaque identifiers)
      • if the cron job also fetched -debugsource subrpms, so debuginfod could index/serve source files too
  • next steps
    • debuginfod client support for abrtd (upstream development work)
    • looking around the abrtd staging server to check file naming conventions now in use, to see if debuginfod can hitch a ride right now

With respect to the fedora-initiative process, IMHO we should go ahead with it independently of all this. e.g. security aspects still need a good airing-out. The longer term future may be a smaller abrtd that becomes a client of debuginfod, where they happen to run together in the same VM, maybe with repurposed storage.

Login to comment on this ticket.