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?

I'm pretty sure it's just the normal fluent bit base image with a watcher on top

I've got it running already and undergoing testing as we speak. A little misleading to call the binary

fluentbit

but renaming it to

-watcher

at image construction time. I'm getting there. BTW, I owe you two.

No worries, submit some PRs to improve it as OSS as well if you want 🙂 Having it buried away was hard to find too - it may be better to move to a two-container pod solution like the helm chart does with reloading, then it could just be the standard FB image

I know I have no rights because I am not a project maintainer.. but man, sometimes is frustrating to submit PRs just to get ignored. I'm not even talking about this particular project but in general. Also I understand I'm in my little bubble of requirements which does not necessarily overlap with the rest of the contributors. Will take care of your suggestion.

Yeah I can appreciate that, I try to help folks who do contribute if I can but Github notifications also are crappy

No worries, mate. Remember the two.

this is what I meant by the helm chart approach: https://github.com/fluent/helm-charts/blob/020afc5526c289ed9e8a2fb1cf66a46995e305ca/charts/fluent-bit/values.yaml#L522 It runs two containers in the pod, normal FB container plus a reloader one that triggers the hot-reload interface when config map changes - I'm not sure what the watcher does, it may restart the FB process or it may trigger hot reload as well but it's the same approach just all--in-one container

Yes - this could probably be simplified so that we can just use upstream images. The source for fluent-watcher lives here: https://github.com/fluent/fluent-operator/blob/master/cmd/fluent-watcher/fluentbit/main.go

yeah multi-process containers are an anti-pattern generally so be good to go direct 🙂

This is an old legacy artifact that needs to be dealt with.

if we can follow the pattern the helm chart does with the side car that might be good enough, otherwise there's reloader but that will roll the pods