Skip to content

NETOBSERV-595 add kafka compression option#2593

Open
jpinsonneau wants to merge 1 commit intonetobserv:mainfrom
jpinsonneau:595
Open

NETOBSERV-595 add kafka compression option#2593
jpinsonneau wants to merge 1 commit intonetobserv:mainfrom
jpinsonneau:595

Conversation

@jpinsonneau
Copy link
Member

@jpinsonneau jpinsonneau commented Mar 25, 2026

Description

  • Allow setting kafka compression for Kafka deployment model and exporter.
  • Added a doc about expectations
  • Default to lz4 as it's the best tradeoff

Observations

On a small 2 nodes clusters, I see a 25% / 600MB gain on kafka overall memory usage while the amount of bytes transfered between kafka pool and eBPF / FLP is reduced by 50% with a similar CPU consumption in both scenarios.
However, eBPF agents and FLPs CPU is slightly increased with compression enabled and memory usage is 50% higher (250MB).

On my scenario, I'm still gaining 350MB in memory enabling compression.

Assisted-by: claude-4.6-opus-high for documentation

Dependencies

netobserv/flowlogs-pipeline#1220
Note: eBPF agent already handle kafkaCompression https://github.com/netobserv/netobserv-ebpf-agent/blob/release-1.11/pkg/config/config.go#L200-L202

Checklist

  • Does the changes in PR need specific configuration or environment set up for testing?
    • if so please describe it in PR description.
  • I have added thorough unit tests for the change.
  • QE requirements (check 1 from the list):
    • Standard QE validation, with pre-merge tests unless stated otherwise.
    • Regression tests only (e.g. refactoring with no user-facing change).
    • No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team).

Summary by CodeRabbit

  • New Features

    • Added optional Kafka message compression configuration. Users can now select compression codecs (none, gzip, snappy, lz4, zstd) for Kafka brokers, with lz4 as the default.
  • Documentation

    • Added comprehensive guide on Kafka compression settings, codec selection recommendations, and compression/performance trade-offs.

@openshift-ci
Copy link

openshift-ci bot commented Mar 25, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign oliviercazade for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jpinsonneau jpinsonneau added the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Mar 25, 2026
@github-actions
Copy link

New images:

quay.io/netobserv/network-observability-operator:bc36f6d
quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-bc36f6d
quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-bc36f6d

They will expire in two weeks.

To deploy this build:

# Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:bc36f6d make deploy

# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-bc36f6d

Or as a Catalog Source:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: netobserv-dev
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-bc36f6d
  displayName: NetObserv development catalog
  publisher: Me
  updateStrategy:
    registryPoll:
      interval: 1m

@github-actions github-actions bot removed the ok-to-test To set manually when a PR is safe to test. Triggers image build on PR. label Mar 25, 2026
@codecov
Copy link

codecov bot commented Mar 25, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.22%. Comparing base (046989f) to head (e8c8627).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2593      +/-   ##
==========================================
- Coverage   72.39%   72.22%   -0.17%     
==========================================
  Files         105      105              
  Lines       10851    10853       +2     
==========================================
- Hits         7856     7839      -17     
- Misses       2518     2536      +18     
- Partials      477      478       +1     
Flag Coverage Δ
unittests 72.22% <100.00%> (-0.17%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
api/flowcollector/v1beta2/flowcollector_types.go 100.00% <ø> (ø)
internal/controller/ebpf/agent_controller.go 66.79% <100.00%> (+0.06%) ⬆️
internal/controller/flp/flp_pipeline_builder.go 71.48% <100.00%> (-2.15%) ⬇️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@memodi
Copy link
Member

memodi commented Mar 25, 2026

@coderabbitai review

@coderabbitai
Copy link

coderabbitai bot commented Mar 25, 2026

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@coderabbitai
Copy link

coderabbitai bot commented Mar 25, 2026

📝 Walkthrough

Walkthrough

This PR adds support for configurable Kafka message compression in the FlowCollector operator. A new optional Compression field is introduced across the API types, CRD schemas, and controller logic with enum constraints limiting values to none, gzip, snappy, lz4 (default), and zstd. The field is propagated from the FlowCollector spec through the eBPF agent controller and flowlogs-pipeline builder to downstream Kafka clients.

Changes

Cohort / File(s) Summary
API Types and CRD Definitions
api/flowcollector/v1beta2/flowcollector_types.go, config/crd/bases/flows.netobserv.io_flowcollectors.yaml, bundle/manifests/flows.netobserv.io_flowcollectors.yaml, helm/crds/flows.netobserv.io_flowcollectors.yaml
Added optional compression field to Kafka configuration schemas in spec and exporters arrays with default value lz4 and enum constraint for supported codecs.
Controller Logic
internal/controller/ebpf/agent_controller.go, internal/controller/flp/flp_pipeline_builder.go
Integrated compression field into eBPF agent DaemonSet environment variables and Kafka exporter configuration, reading from spec.Kafka.Compression and injecting into downstream components.
UI and Descriptors
bundle/manifests/netobserv-operator.clusterserviceversion.yaml
Added Compression field descriptor to ClusterServiceVersion UI schema under Kafka configuration section.
Documentation
docs/FlowCollector.md, docs/KafkaCompression.md
Documented the new compression field with supported codec values, default behavior, and detailed explanation of compression codec characteristics and selection recommendations.
Tests
internal/controller/flowcollector_controller_iso_test.go
Updated test spec to include Compression: "lz4" in FlowCollectorKafka configuration for assertion consistency.
Vendor Dependencies
vendor/github.com/netobserv/flowlogs-pipeline/pkg/api/encode_kafka.go
Added Compression field to EncodeKafka struct with documentation of supported codecs.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 Compression comes to Kafka's way,
With lz4 leading the day!
From zstd to snappy so bright,
Messages flow ever light,
A field spreads across the array!

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title 'NETOBSERV-595 add kafka compression option' accurately describes the main change: adding a configurable Kafka compression feature across the codebase.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Description check ✅ Passed PR description covers the main objective and includes observations, dependencies, and QE requirements; however, the 'Does the changes need specific configuration' and 'thorough unit tests' checklist items are unchecked.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (2)
internal/controller/ebpf/agent_controller.go (1)

452-461: Add a regression test for KAFKA_COMPRESSION env propagation.

This mapping is critical to runtime behavior; a focused controller test asserting the env var value (lz4 default + explicit override) would help prevent regressions.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@internal/controller/ebpf/agent_controller.go` around lines 452 - 461, The
controller currently sets envKafkaCompression from coll.Spec.Kafka.Compression
when coll.Spec.UseKafka() is true; add a unit/regression test targeting the EBPF
agent controller (e.g., the function that builds pod envs in agent_controller.go
or the method that calls append(config, ...)) that verifies envKafkaCompression
is present and set to the default "lz4" when unspecified and to an explicit
value when provided; in the test construct a Collection/Spec with UseKafka()
true, assert the resulting env list contains corev1.EnvVar{Name:
envKafkaCompression, Value: "<expected>"} for both default and override cases,
and include a case covering coll.Spec.Kafka.Compression being empty to ensure
defaulting behavior is enforced.
docs/KafkaCompression.md (1)

1-52: Consider adding operational guidance for configuration changes.

The documentation is comprehensive and well-written. One optional enhancement: briefly mention what happens when operators change the compression setting on an existing deployment (e.g., whether it requires a rolling restart of the eBPF agent DaemonSet, whether messages already in Kafka are affected, etc.). This would help operators plan configuration changes in production environments.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@docs/KafkaCompression.md` around lines 1 - 52, Add a short "Operational
changes" note explaining that changing spec.kafka.compression or
spec.exporters[].kafka.compression only affects producers (the eBPF agent) and
requires a rolling restart of the eBPF agent DaemonSet to pick up the new codec,
that existing messages already in Kafka are stored with their original codec and
are not rewritten, consumers (flowlogs-pipeline) automatically handle
decompression so no consumer config change is needed, and Kafka brokers need no
restart; also mention that spec.agent.ebpf.kafkaBatchSize and batch boundaries
determine how compression is applied and that operators should plan restarts to
avoid simultaneous DaemonSet pod restarts.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@docs/KafkaCompression.md`:
- Around line 1-52: Add a short "Operational changes" note explaining that
changing spec.kafka.compression or spec.exporters[].kafka.compression only
affects producers (the eBPF agent) and requires a rolling restart of the eBPF
agent DaemonSet to pick up the new codec, that existing messages already in
Kafka are stored with their original codec and are not rewritten, consumers
(flowlogs-pipeline) automatically handle decompression so no consumer config
change is needed, and Kafka brokers need no restart; also mention that
spec.agent.ebpf.kafkaBatchSize and batch boundaries determine how compression is
applied and that operators should plan restarts to avoid simultaneous DaemonSet
pod restarts.

In `@internal/controller/ebpf/agent_controller.go`:
- Around line 452-461: The controller currently sets envKafkaCompression from
coll.Spec.Kafka.Compression when coll.Spec.UseKafka() is true; add a
unit/regression test targeting the EBPF agent controller (e.g., the function
that builds pod envs in agent_controller.go or the method that calls
append(config, ...)) that verifies envKafkaCompression is present and set to the
default "lz4" when unspecified and to an explicit value when provided; in the
test construct a Collection/Spec with UseKafka() true, assert the resulting env
list contains corev1.EnvVar{Name: envKafkaCompression, Value: "<expected>"} for
both default and override cases, and include a case covering
coll.Spec.Kafka.Compression being empty to ensure defaulting behavior is
enforced.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 482a435e-e0d7-4669-9e98-13cad9b41b01

📥 Commits

Reviewing files that changed from the base of the PR and between 046989f and e8c8627.

📒 Files selected for processing (11)
  • api/flowcollector/v1beta2/flowcollector_types.go
  • bundle/manifests/flows.netobserv.io_flowcollectors.yaml
  • bundle/manifests/netobserv-operator.clusterserviceversion.yaml
  • config/crd/bases/flows.netobserv.io_flowcollectors.yaml
  • docs/FlowCollector.md
  • docs/KafkaCompression.md
  • helm/crds/flows.netobserv.io_flowcollectors.yaml
  • internal/controller/ebpf/agent_controller.go
  • internal/controller/flowcollector_controller_iso_test.go
  • internal/controller/flp/flp_pipeline_builder.go
  • vendor/github.com/netobserv/flowlogs-pipeline/pkg/api/encode_kafka.go

Copy link
Contributor

@leandroberetta leandroberetta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thanks @jpinsonneau!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants