FYI: https://github.com/fluent/fluent-operator/issues/1657

If we were to organize a fluent-operator community meeting to discuss release strategy, etc -- what time would be best for everyone? I know we have interested folks and maintainers in a variety of different time zones.

I’m out for 3 weeks camping ⛺ end of this week

I'd say maybe get @Eric D. Schabell / @eduardo to ask as well in the existing Fluent office hours/community meeting so more folks are aware

Hi! Not sure if this is the right channel, but could someone help review this PR for the Fluent Operator Helm chart? It’s a small change that just adds extra labels to the Operator’s Deployment. I’m not the author, but I’m also waiting on it. https://github.com/fluent/helm-charts/pull/623

I have 2 PRs trying to get this operator back on track and work towards a release: • https://github.com/fluent/fluent-operator/pull/1703 • https://github.com/fluent/fluent-operator/pull/1702 @Josh Baird @Chengwei Guo any of you able to review?

Couple more: • https://github.com/fluent/fluent-operator/pull/1706 • https://github.com/fluent/fluent-operator/pull/1705 • https://github.com/fluent/fluent-operator/pull/1704 Please merge in this order. After I will rebase https://github.com/fluent/fluent-operator/pull/1702 to reduce the diff to make review easier. @Josh Baird @Chengwei Guo Once above is all done, I have couple more PRs coming up to resolve linter warnings (cyclomatic complexity, and long lines), would be great to get the codebase cleaned up a little for easier maintenance

@here Would appreciate some community help to get this project back on track https://github.com/fluent/fluent-operator/issues/1707

https://github.com/fluent/fluent-operator/pull/1702 ready for review

https://github.com/fluent/fluent-operator/pull/1708 another one ready for review

https://github.com/fluent/fluent-operator/pull/1715 one more

https://github.com/fluent/fluent-operator/pull/1710 and another one

Hello, https://github.com/fluent/fluent-operator/issues/1719 I posted this issue and started working on a PR But when i build with the make file and i use that to test but i run into an error I don't have the context of this one but tried to build with no changes on code and same error happened so i told my self it's my way of building it that doesn't work!! So if some one has any idea

2025-10-10T14:52:56Z    ERROR    setup    unable to create controller    {"controller": "FluentBit", "error": "controller with name fluentbit already exists. Controller names must be unique to avoid multiple controllers reporting the same metric. This validation can be disabled via the SkipNameValidation option"}
 main.main
     /workspace/main.go:282
 runtime.main
     /usr/local/go/src/runtime/proc.go:283

Another issue where we could use some community help https://github.com/fluent/fluent-operator/issues/1733

So - as I was testing

master

before cutting a release, it seems we're hitting this again: https://github.com/fluent/fluent-operator/issues/1559

Fixes tag generation for building operator images: https://github.com/fluent/fluent-operator/pull/1740

Release v3.5.0 of the fluent-operator helm-chart: https://github.com/fluent/helm-charts/pull/651

🎉 fluent-operator v3.5.0 has been released! https://github.com/fluent/fluent-operator/releases/tag/v3.5.0

i feels like we need a project for managing critical or medium-size or large-size issues for fluent-operator, just like the fluentd https://github.com/orgs/fluent/projects/4 @Josh Baird @Marco Franssen what do you think?

Hi guys, We are using Fluent Bit Operator on AKS and we need to collect Prometheus metrics exposed by application pods across multiple namespaces. Our goal is to scrape /metrics endpoints from all pods that define Prometheus scrape annotations, similar to how Prometheus Service Discovery works. The problem is that Fluent Bit Operator’s ClusterInput CRD only seems to expose the prometheusScrapeMetrics input, which requires static host/port configuration, we basically need to scrape metrics from dynamic workloads across AKS without manually defining each endpoint. Has anyone faced this limitation? Does fluent bit have anything that we might be missing that could address this? Thanks in advance

I'd like to start a conversation about Helm chart/release improvements -- starting with how we're handling CRDs 🧵

Hi all, Let me explain you my sorrows. I've got a

ClusterOutput

in my cluster of type

s3

but the actual S3 object stroage service is provided by an EMC ViPR Controller (think of it as an appliance by DELL providing an S3 compatible service). The issue arises when doing multipart uploads: unlike the actual AWS S3 service, ECM ViPR issues ETag header names in small letters (as RFC9110 states) but FluentBit expects the header name

ETag:

thus ongoing multipart uploads get aborted. Sad. The fix in FluentBit is easy: replace

strstr(3)

with

strcase(3)

in the right place (a 4 bytes diff so to speak). The issue I am having however is building a FluentBit container image "compatible enough" with the Fluent Bit Operator. That is a container image that the operator can call into execution... and behave like a regular image provided by kubesphere. Could someone point me to the repo where the Kubesphere repo (if public) with the code for building the container image so I could patch things and build something suitable for my purposes?

Ok - here is a draft PR of the v4 re-factor: https://github.com/fluent/fluent-operator/pull/1869

Hey everyone, I created an issue and put up a PR today for adding support for the multiline_buffer_limit configuration value. I'm currently either having to allow fluent bit to get OOMKilled, or allocate it a large amount of memory, since the multiline cri parser doesn't respect buffer limits. Would appreciate any feedback or thoughts on getting this added.

What is required to get a new release for the operator helm chart out?

@Chris Geirman joined #fluent-operator. They’re also new to Fluent.

@Chris Geirman joined #fluent-operator. They’re also new to Fluent.

👋 Heads up — we're moving to the CNCF Slack! Our chapter Slack is closing next month and we're consolidating into the CNCF Slack where the broader Fluent Bit community lives. Come join us over there! 🔗 Join here: https://communityinviter.com/apps/cloud-native/cncf Once you're in, find us in these channels: • #C0CTQGHKJ • #fluentd-fluentbit • #fluent-bit-channel • #C0CTT63EE Don't forget to update any saved bookmarks or links to this workspace — it'll be gone at the end of May. See you on the other side! 🎉

@Chengwei Guo @Marco Franssen Could I get a review on https://github.com/fluent/helm-charts/pull/723 please?