Skip to content

oss-standalone-redisearch-m5: port parca-agent config from m7#158

Open
paulorsousa wants to merge 1 commit into
masterfrom
fix/m5-parca-agent-projectid
Open

oss-standalone-redisearch-m5: port parca-agent config from m7#158
paulorsousa wants to merge 1 commit into
masterfrom
fix/m5-parca-agent-projectid

Conversation

@paulorsousa
Copy link
Copy Markdown
Contributor

Summary

Port the oss-standalone-redisearch-m7 parca-agent cloud-init + variables to the oss-standalone-redisearch-m5 module so dispatches that pick the m5 setup also emit profiles to Polar Signals.

Root cause

The m5 cloud-init-parca-agent.yaml only set:

snap set parca-agent remote-store-bearer-token=<token>

With a psc_v1_<secret>_<projectId> style token (no project binding inside the token claims) and parca-agent v0.47+, the agent requires:

snap set parca-agent remote-store-grpc-headers=projectID=<id>

…or every profile is silently dropped at the remote-store. The m7 module already has this. Dispatching Run RediSearch Benchmarks against redislabsdev/RediSearch with allowed_setup=oss-standalone (which picks m5) produces 0 profile samples in the configured Polar Signals project despite enable_parca_agent=true and the agent showing as active on the bench-server.

Change

m5 now mirrors m7:

  • variables.tf: add parca_agent_project_id (default "") + parca_agent_snap_channel (default "stable"). Defaults preserve current behaviour for callers that only pass the token.
  • db-resources.tf: thread both new vars through the templatefile call.
  • cloud-init-parca-agent.yaml: replace the truncated install/snap-set block with the full m7 version — relabel_configs file (__meta_process_executable_name keep-on-redis-server, thread/pid label promotion, role default), the remote-store-grpc-headers=projectID=… snap setting, and the channel pin so parca_agent_snap_channel: edge picks up v0.47.1+.

After this lands, a redislabsdev/RediSearch dispatch with allowed_setup=oss-standalone will produce per-test profiles in Polar Signals labeled with the same test_name / git_hash set the m7 module already emits.

Test plan

  • Re-dispatch Run RediSearch Benchmarks workflow on redislabsdev/RediSearch with allowed_setup=oss-standalone, enable_parca_agent=true, valid parca_agent_project_id
  • Verify git_hash label value matching the dispatched SHA appears in Polar Signals (project 73d7b9ec-…)
  • Confirm test_name filter narrows samples to a single test as expected
  • Confirm relabel_configs keeps only redis-server samples (no agent / runtime noise)

🤖 Generated with Claude Code

The m5 cloud-init only set `remote-store-bearer-token`; with a
`psc_v1_<secret>_<id>` token (no project id embedded in the JWT
claims), parca-agent v0.47+ silently drops profiles unless a
`--remote-store-grpc-headers=projectID=<id>` is also set. That is
why redislabsdev/RediSearch benchmark dispatches against this setup
produce 0 profile samples in the redisearch Polar Signals project.

This change makes m5 match the m7 module:

* Add `parca_agent_project_id` and `parca_agent_snap_channel` vars
  (defaults preserve current behaviour: empty project id, `stable`
  channel — so existing callers passing only the token still work).
* Thread the new vars through the `templatefile` call.
* Rewrite the cloud-init to mirror m7: relabel_configs file pinning
  to `redis-server` and promoting thread/pid labels, plus the
  `remote-store-grpc-headers=projectID=...` snap setting and the
  channel pin.

Result: oss-standalone dispatches with `enable_parca_agent=true`
and a `psc_v1_*` token will emit profiles to the configured
Polar Signals project, with `test_name`/`git_hash`/etc labels.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant