Review `parca-agent` for listing

charmhub requests review requests
1

Parca Agent is an always-on sampling profiler that uses eBPF to capture raw profiling data with very low overhead. It observes user-space and kernel-space stacktraces 19 times per second and builds pprof formatted profiles from the extracted data. Read more details in the design documentation.

The collected data can be sent to a Parca server to be queried and analysed over time.

This operator is a subordinate, meaning it can be combined with any other operator to provide profiling capability at the machine level.

PR for code review: parca-agent-operator/pull/68

Metadata links

CI Links

Documentation Links

2

Thanks @ppasotti for the review request!

@shayanp can you please help with this review? You can go through and tick off the items on the checklist and post the result in this thread. This prior listing request could serve as an example of how to go about it. Please ping me or anyone from Charm-Tech for any questions.

Note that the parca-scrape-target and parca-k8s-operator charms are also being reviewed at the moment, but I think the reviews can all be done independently (maybe the latter would be useful for demo’ing/trying out this one alongside a machine charm you know well?).

3

Yes, just as an update, the review is currently in progress

1 Like
4

Checklist detailing the review:

Checked Comment Review item Objective Review criteria
✓ Was able to deploy parca in a k8s model and integrate parca-agent with postgres 16/edge charm (based on noble) and see profiles flow through to the parca server Intended functionality Despite all the items for publication readiness, the charm must work. Charm does what it is meant to do - ideally done in a demo.
✓ The charmed-parca documentation documentation is not the same as the docs on the charmhub page Details of product specific documentation included in followup reply Charmhub.io charm detail page A complete and consistent appearance of the charm is required for a quality impression of the charm collection. The overall appearance looks good, which means: * The name complies with the naming guidelines . * The publisher is identified. * The links are provided. * The documentation looks reasonable.
✓ Source repository Generally, the source code for charms must be accessible by the community for transparency and collaboration. It is not entirely mandatory to have the charm published as OSS for review, but the repository must be accessible from the persons working on the review request.
✓ Confirmed usage of ruff for linting. Confirmed CI lint step on PRs Coding conventions The source code of the charm is accessible in the sense of approachability. Consistent source code style and formatting are also considered a sign of being committed to quality. The implemented checks for coding conventions are reasonable and implemented in the regular CI/CD implementation.
✓ Confirmed CI step for release. Confirmed CI for release to edge upon push to main Release automation implementation An implementation for automated releasing to charmhub.io improves the ability to provide updates covering vulnerabilities quickly. Release automation for unstable channels to enable testing when new versions of the charm code or the workload become available.
✓ Confirmed implementation of scenario tests. CI test runs displays coverage. Unit tests implementation In particular, for the charms review, assuring a reasonable test suite is essential to allow for automated releases in future. The unit tests show relevant coverage. It is a case-dependent review.At the time of review, the test runs successfully.
✓ Unit tests results Availability of test results is mandatory for a working collaborative project. URL to test results from CI/CD automation.
✓ Confirmed implementation of a deployment/installation test. Installation test implemented (could be part of the integration test) In particular, for the charm review, assuring a reasonable test suite is essential to allow for automated releases in future. With this test, for every build, it is ensured that the installation is successful. An implementation for checking the installation is present. The implementation should also check for successful installation as part of the automation, and the workload behaves as expected. At the time of review, the test runs successfully.
✓ Test run upon release to edge and run in PRs Installation test results Availability of test results is mandatory for a working collaborative project. URL to test results from CI/CD automation.
✓ Tests for integration with ubuntu exist. May be good, in the future, to test fully with a backend store Integration tests implemented In particular for the review of charms, assuring a reasonable test suite is important to allow for automated releases in future. With this test, for every build, it is ensured that the integration with other charms is successful. An implementation for testing the required integrations (if applicable) is present. The implementation should also check for successful integration as part of he automation and the workload behaves as expected. At the time of review, the test runs successfully.
✓ Integration test results Availability of test results is mandatory for a working collaborative project. URL to test results from CI/CD automation.
✓ Documentation for usage is not linked to the charm’s charmhub page Details of product specific documentation included in followup reply Documentation for usage The documentation for using the charm should be separate from the documentation for developing or contributing to the charm. URL to this documentation is present.
✓ Documentation for contributing The documentation for contributing to the charm should be separate from the documentation for developing or using the charm. URL to this documentation is present.
✓ Licensing statement For the charm shared, OSS or not, the licensing terms of the charm are clarified (which also implies an identified authorship of the charm). URL to the ruling licensing statement is present.
1 Like
5

As far as I can see the only concern are about the documentation. Some clarification about the choices we made here:

the “parca solution”, which is the product, is what we want to highlight in our user-facing docs. The solution consists of three components (the parca-agent, parca-k8s, and parca-scrape-target charm).

Each charm has its own set of docs, which only includes the documentation that is specific to the charm in question. All documentation which applies to the whole solution is attached to the solution-level docs (“charmed parca documentation”).

Each charm doc index points back to the solution-level docs:

image
image731×132 18.2 KB

And the solution-level docs point to the individual charm’s.

image
image694×168 36.3 KB

TLDR:

image
image1233×557 56.3 KB

Also, the docs index is linked, but will only show if you select ‘edge’ on charmhub, as the release containing that link hasn’t yet been rolled into stable.

2 Likes
6

Sorry for the delay here, but the checklist and the charm looks good to me @tony-meyer. Was able to test the integration end-to-end with parca-k8s and postgres 16/edge (noble). There are a couple followups unrelated to parca-agent that arose as part of my testing, and I have communicated these with the observability team

1 Like