Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Record a backend's capability profile when it joins a pool, not only on an explicit ProfileBackend call (follow-up to #681)

Closed
  • Is something wrong?
#2,136 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
64/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
api, backend, distributed-systems, testing-qa

Research direction

Start by tracing the ProfileBackend RPC handler, capabStore().Record, the pool-join or daemon startup path, and GetCapabilityProfile. Reuse the existing bounded benchmark path and inspect current tests around these entry points. Done means join-time profiling is best effort, preserves existing profiles, remains compatible with explicit profiling, and covers all four acceptance-test cases.

Written by the indexing model from the issue text.

Description

enhancement good first issue

Follow-up from the acceptance check on #681 (see the comment there). #684 implemented the profile, but its first acceptance line ("join records a capability profile") is not met as written; #684's description lists this as a known follow-up.

Problem

The only place a capability profile is recorded is inside the ProfileBackend RPC handler (capabStore().Record). Nothing records one when a backend joins a pool or is first discovered, so a backend has no profile unless someone calls POST /v1/capabilities/profile by hand. Placement by measured capability, the whole reason for #681, therefore only works for backends an operator remembered to profile.

A profile describes the host it is measured on, so it has to be produced on the joining backend. Decide, and state in the PR, whether the joiner self-profiles once it has joined (a startup step that runs when the daemon finds it belongs to a pool and has no profile) or the primary asks the joiner to profile itself at join time.

Acceptance criteria

  • Joining a pool (or a daemon starting as a pool member with no profile) records a profile automatically, using the same code path and the same bounded benchmark as ProfileBackend.
  • Recording is best effort and never blocks or fails the join: a benchmark or GPU-probe failure is logged and leaves no profile, and a later explicit ProfileBackend still works.
  • It does not re-profile a backend that already has a profile, unless asked explicitly.
  • After join, GetCapabilityProfile returns the recorded profile without a manual call.
  • Tests cover: join records a profile; benchmark failure does not fail the join; an existing profile is not overwritten; the explicit RPC still works.

Refs #681, #684.

Dominant language
Go
Stars
296
Forks
38
Avg merge
8h 18m
Merged PRs (30d)
559

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from FootprintAI/Containarium

All issues in FootprintAI/Containarium

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.