Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Support for Canonical Snap builds to run on Ubuntu Core #17199

Draft
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

ralphm
Copy link
Member

@ralphm ralphm commented Mar 19, 2024

Summary

Provide the ability to create a Snap package for Netdata Agent and associated utilities.

Test Plan

TBD

Additional Information

This worked is based on a request for supporting Ubuntu Core, which is primarily used in IoT settings, but is also the framework within which (most) Snaps run.

This PR takes a different approach than #1991, in that instead of a full build as part of the snapcraft building process, it takes the static builds and packages them. That PR had a request to move the snap directory to another place than the root of the repo, but snapcraft makes this very hard, and if we decide to make a huge point on this, there may be some avenues I can try, but it most likely means that the YAML file will be .snapcraft.yaml and other things like hooks need to be populated explicitly.

The major issue with running the Agent in this environment is providing sufficient permissions in the strict confinement model, through so-called plugs for interfaces.

This minimal snap downloads the kickstart.sh script during the pull
stage, executes the script without starting the Agent, and then ensures
it is properly packed.

This only awards the `network` and `network-bind` plugs to the Agent,
and the `network` plug for the claim script.
This includes many `disk.*` metrics, cpu and memory pressure,
`system.io`.
This includes `ip.*`, `ipv4.*`, `ipv6.*`, `wireless.*` and
`netfilter.conntrack_sockets`.
This is the only plug that provides wide read access to other processes'
properties, opening up proper metrics on file descriptors and limits.

However, I don't think this is proper and `snapd` should expose another
way to get this type of access, because it isn't necessarily beholden to
using Docker.
@ralphm ralphm requested a review from Ferroin as a code owner March 19, 2024 18:20
@ralphm ralphm marked this pull request as draft March 19, 2024 18:20
@ralphm
Copy link
Member Author

ralphm commented Mar 19, 2024

I'm still working on figuring out which interfaces provide enough permissions to the Agent. Among other things, hardware-observe causes a segfault. My progress on which interfaces provide which "new" metrics and functionality is documented in individual commits. Also note that because user management works differently in Snaps, I explicitly let the Agent run as root.

This enables `cgroups.plugin` to access unified cgroups files in
`/sys/fs/cgroup` and emit metrics for cgroups of various kinds,
including systemd services.

Note that systemd user slices (and their child slices) are disabled by
default by the plugin.
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.

None yet

1 participant