packaging: add strict snapcraft packaging for Netdata on Ubuntu Core by Half-Silver · Pull Request #21785 · netdata/netdata
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3 issues found across 4 files
Confidence score: 3/5
snapcraft.yamlenables debugfs.plugin under strict confinement without an interface, so it will be denied at runtime and functionality relying on it may fail.snapcraftignoreexcludes the SNMP metadata overrides directory, which can cause SNMP overrides to be missing at runtime- The issues are user-impacting for strict snaps, which raises regression risk despite no other major concerns noted
- Pay close attention to
snapcraft.yaml,.snapcraftignore- confinement and runtime data access behavior.
Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".snapcraftignore">
<violation number="1" location=".snapcraftignore:14">
P2: The snapcraft ignore list excludes the SNMP metadata overrides directory, but the SNMP utilities load YAML overrides from this path at runtime. Removing it from the snap will cause SNMP overrides to be missing, degrading SNMP profile detection/normalization.</violation>
</file>
<file name="snapcraft.yaml">
<violation number="1" location="snapcraft.yaml:60">
P2: debugfs.plugin is enabled under strict confinement without any interface granting access to /sys/kernel/debug, which the plugin requires; it will be denied at runtime. Disable the plugin or add an appropriate interface.</violation>
</file>
<file name="packaging/snap/README.md">
<violation number="1" location="packaging/snap/README.md:67">
P2: Smoke-test instructions use `--devmode`, which disables strict confinement and can hide missing interface/permission issues for a strict snap. This undermines the purpose of testing strict confinement.</violation>
</file>
Architecture diagram
sequenceDiagram
participant Builder as Build Env (LXD/CI)
participant Git as External Repos
participant snapd as Ubuntu Core (snapd)
participant Wrapper as bin/run-netdata
participant Daemon as Netdata Daemon
participant Sys as System (Kernel/debugfs)
Note over Builder,Git: NEW: Managed Build Flow (core24)
Builder->>Builder: override-pull: Read packaging/version
opt Submodules Missing
Builder->>Git: NEW: Fetch pinned aclk-schemas
Builder->>Git: NEW: Fetch pinned lm-sensors
end
Builder->>Builder: CMake: Enable apps.plugin & debugfs.plugin
Builder-->>snapd: Produce .snap (Strict Confinement)
Note over snapd,Sys: NEW: Runtime Control Flow
snapd->>Wrapper: Start Service (daemon)
rect rgb(23, 37, 84)
Note right of Wrapper: Environment Initialization
Wrapper->>Wrapper: Set writable paths ($SNAP_DATA, $SNAP_COMMON)
Wrapper->>Wrapper: NEW: Initialize sensors.conf for thermal support
Wrapper->>Wrapper: Set PATH to include snap binaries
end
Wrapper->>Daemon: NEW: exec with -W path overrides
rect rgb(5, 46, 22)
Note right of Daemon: Strict Monitoring (Interface Plugs)
Daemon->>Sys: NEW: system-observe (Process monitoring)
Daemon->>Sys: NEW: hardware-observe (Thermal/debugfs)
Daemon->>Sys: network-observe (TCP/UDP sockets)
end
alt Data Request
Sys-->>Daemon: Return metrics (thermal, app cpu, etc.)
Daemon-->>Daemon: Aggregate metrics
else Unauthorized Access
Sys-->>Daemon: Blocked by Strict Confinement
end
Note over Daemon: Listener: 19999
Since this is your first cubic review, here's how it works:
- cubic automatically reviews your code and comments on bugs and improvements
- Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
- Add one-off context when rerunning by tagging
@cubic-dev-aiwith guidance or docs links (includingllms.txt) - Ask questions if you need clarification on any suggestion
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.