Updates/packaging for srql #2237
No reviewers
Labels
No labels
1week
2weeks
Failed compliance check
IP cameras
NATS
Possible security concern
Review effort 1/5
Review effort 2/5
Review effort 3/5
Review effort 4/5
Review effort 5/5
UI
aardvark
accessibility
amd64
api
arm64
auth
back-end
bgp
blog
bug
build
checkers
ci-cd
cleanup
cnpg
codex
core
dependencies
device-management
documentation
duplicate
dusk
ebpf
enhancement
eta 1d
eta 1hr
eta 3d
eta 3hr
feature
fieldsurvey
github_actions
go
good first issue
help wanted
invalid
javascript
k8s
log-collector
mapper
mtr
needs-triage
netflow
network-sweep
observability
oracle
otel
plug-in
proton
python
question
reddit
redhat
research
rperf
rperf-checker
rust
sdk
security
serviceradar-agent
serviceradar-agent-gateway
serviceradar-web
serviceradar-web-ng
siem
snmp
sysmon
topology
ubiquiti
wasm
wontfix
zen-engine
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
carverauto/serviceradar!2237
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refs/pull/2237/head"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Imported from GitHub pull request.
Original GitHub pull request: #1657
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/1657
Original created: 2025-09-24T14:19:18Z
Original updated: 2025-09-24T14:40:14Z
Original head: carverauto/serviceradar:updates/packaging_for_srql
Original base: main
Original merged: 2025-09-24T14:39:01Z by @mfreeman451
PR Type
Enhancement
Description
Add complete packaging infrastructure for SRQL service
Implement OCaml build pipeline with Docker support
Create systemd service configuration and installation scripts
Update database schema TTL policies for optimization
Diagram Walkthrough
File Walkthrough
7 files
Add SRQL service post-installation scriptAdd SRQL service pre-removal scriptAdd SRQL component configurationAdd RPM spec file for SRQLAdd SRQL environment configurationAdd systemd service definition for SRQLUpdate database TTL policies to 3 days5 files
Add OCaml Docker build supportAdd SRQL OCaml builder Docker imageUpdate SRQL Docker build configurationAdd RPM package builder for SRQLAdd standalone SRQL build Dockerfile1 files
Fix OCaml syntax for query execution2 files
Update OCaml dependencies and versionsUpdate OPAM dependencies and constraints1 files
Imported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/1657#issuecomment-3328786482
Original created: 2025-09-24T14:20:06Z
PR Reviewer Guide 🔍
Here are some key observations to aid the review process:
Insecure defaults:
The environment file sets weak defaults (e.g., SRQL_API_KEY=changeme) and disables TLS verification (PROTON_INSECURE_SKIP_VERIFY=1, PROTON_VERIFY_HOSTNAME=0). If deployed without modification, this can allow unauthorized access and MITM risks. Recommend documenting required overrides, enforcing non-empty secure API key at startup, and defaulting to strict TLS verification.
Fragile Pinning
Dream and Proton are pinned via git refs and local sed to relax h2 constraints; this could break reproducibility or silently change dependency sets. Consider pinning exact versions/tags and avoiding in-place edits if possible.
Insecure Defaults
Default credentials and TLS verification disabled (API key 'changeme', PROTON_* insecure flags) risk accidental insecure deployments. Prefer safe defaults or force overrides at install.
Docker Copy Path
The ocaml build step copies from a container path that may be a directory; docker cp semantics differ for file vs directory. Validate that docker_output_path and output_path handling results in a single executable at the desired path across DEB/RPM builds.
Imported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/1657#issuecomment-3328794916
Original created: 2025-09-24T14:21:31Z
PR Code Suggestions ✨
Explore these optional code suggestions:
Consolidate the inconsistent OCaml build logic
The PR's multiple Dockerfiles use conflicting OCaml versions and dependency
strategies, such as patching
dreamversus pinning older versions. This should beunified into a single, consistent build process to reduce fragility and improve
maintainability.
Examples:
docker/compose/Dockerfile.srql [4-40]
docker/rpm/Dockerfile.rpm.srql [3-66]
Solution Walkthrough:
Before:
After:
Suggestion importance[1-10]: 9
__
Why: The suggestion correctly identifies significant inconsistencies in OCaml versions and dependency management across multiple new Dockerfiles, which introduces fragility and maintenance overhead.
Justify the aggressive data retention reduction
The PR significantly shortens data retention TTLs for core data streams from
30/7 days to 3 days. This major policy change risks data loss for users needing
historical data and requires clear justification and impact analysis.
Examples:
pkg/db/migrations/00000000000001_consolidated_serviceradar_schema.up.sql [36]
pkg/db/migrations/00000000000001_consolidated_serviceradar_schema.up.sql [183]
Solution Walkthrough:
Before:
After:
Suggestion importance[1-10]: 8
__
Why: This suggestion highlights a critical, non-obvious change to data retention policy that could lead to significant data loss and impact users relying on historical data, warranting careful justification.
Preserve config file permissions on upgrade
In the
%postscriptlet, only set permissions on/etc/serviceradar/srql.envduring initial package installation (
$1 == 1) to avoid overwriting custompermissions on upgrades.
packaging/specs/serviceradar-srql.spec [42-45]
[To ensure code accuracy, apply this suggestion manually]Suggestion importance[1-10]: 7
__
Why: The suggestion correctly identifies that permissions on a configuration file are being reset on every upgrade, and proposes the standard RPM packaging fix to only set them on initial install.
Pin opam repository for reproducible builds
For reproducible builds, pin the opam repository to a specific commit hash
instead of fetching from the
masterbranch.docker/rpm/Dockerfile.rpm.srql [49-54]
Suggestion importance[1-10]: 6
__
Why: The suggestion correctly identifies a non-reproducible build step and proposes a standard best practice to fix it, which improves build stability and reliability.
Imported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/1657#issuecomment-3328814930
Original created: 2025-09-24T14:26:02Z
CI Feedback 🧐
A test triggered by this PR failed. Here is an AI-generated analysis of the failure:
Action: build-test
Failed stage: Install dependencies (with tests) [❌]
Failure summary:
The action failed due to an opam dependency resolution conflict:
- The environment pins
ocaml-base-compiler = 5.3.0(invariant), but dependencies pulled bydeps-of-srql-translator → dream≥ 1.0.0requirealpha7 → dream-httpaf ≥ 1.0.0alpha4 → h2 < 0.13.0 → hpack = 0.11.0ocaml < 5.3(andin some paths
ocaml < 5.0).- This creates incompatible constraints with
ocaml-base-compiler =5.3.0, conflicting withdkml-base-compilerandocaml-variants.- Additional missing dependencies are
gated by availability conditions:
-
ocaml-betarequiresenable-ocaml-beta-repository.-
system-msvcrequiresos = "win32".- opam exits with a package conflict error (exit code 20),
causing the job to fail.
Relevant error logs: