Pat

My main concern around this is having a bespoke CRD for every plugin: a plugin has it's own configuration which is essentially bespoke per plugin and then we wrap this...

> Finally, I don't think this conversation is a tangent from the original question. Changing the CRD architecture shouldn't be a blocker on iterating on plugin backfill. Agreed. I would...

> Processing logs is the advantage of fluentbit and I don't think OpenTelemetry collector can be better. So supporting OTLP logs via fluentbit is exciting just like collecting OTLP metrics...

Ah right, sorry it wasn't clear. An extension of the existing OTEL output to include logs as well as the current metrics (and traces coming): https://docs.fluentbit.io/manual/pipeline/outputs/opentelemetry That's probably an enhancement...

Looks reasonable to me, would this also enable custom plugins if people build those into their container image? Rather than a named one supported by OSS but some bespoke Golang...

> > [PLUGINS] > > path /a/path/libplugin1.so > > path /b/path/libplugin2.so > > Where should these plugin paths be added? FluentBit itself has a separate configuration mechanism for this? Yup,...

Seems reasonable to me, although I'd probably try to use the metadata action with Github and just push all images regardless to GHCR.io apart from possibly PRs as they'll need...

We're doing all this for Fluent Bit so makes sense to me - we're also pushing to ghcr.io there and then only promoting to DockerHub for releases. Note for PRs...

Yeah, we cannot merge docs until the release though - otherwise it confuses people when they see docs for something only on a `master` build.

@lecaros not sure how we tag waiting for release or should this merge to master in advance of 2.0?