plugin_proxy: enable event_type specification for proxy plugins (4.2 Backport)

[jmccormick7]

This PR adds event_type to the flb_plugin_proxy_def struct. This allows for the setting of event_type to a value other than the default log only initialization.

This PR is a backport for FluentBit 4.2 that matches the approved changes in PR #11011

In the flb_plugin_proxy_register function default behavior is enforced by checking for unset event_type values. When unset (a value of 0) then log behavior is defaulted. No need for incorrect value checking since this was not a set field in the past. Unset fields are set as current behavior dictates and future use cases using incorrect values can be treated as user error.

Input use case does not use event-type and is unaffected by this change.

Addresses #10995

This corresponding PR in the fluent-bit-go library enables the ability to allow Go plugins to register their event types fluent/fluent-bit-go#80

---

Enter [N/A] in the box, if an item is not applicable to your change.

Testing
Before we can approve your change; please submit the following in a comment:

• Example configuration file for the change
• Debug log output from testing the change

• Attached Valgrind output that shows no leaks or memory corruption was found

If this is a change to packaging of containers or native binaries then please confirm it works for all targets.

• Run local packaging test showing all targets (including any new ones) build.
• Set ok-package-test label to test for all targets (requires maintainer to do).

Documentation

• Documentation required for this feature

Backporting

• Backport to latest stable release.

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[jmccormick7]

@cosmo0920 I added this and one other pr (back porting to 4.1). I saw that the main pr was added to the 5.0 milestone. I just wanted to ask about the possibility of getting the back port in an earlier release for 4.2 as this is backwards compatible. I completely understand if it's preferred to wait until a major release as it is a feature change. I just figured it was worth checking in on to see if it could get released sooner. I'm more than happy to do anything additional that may be needed to support this if there's anything missing or areas where this falls short. Thanks!

[cosmo0920]

This good to be merged for 4.2 branch.
But we need to proceed to review and merged into master at first here:
#9735

[cosmo0920]

So, can we process and merge #9735 at first, @edsiper?
For me, that PR is good enough to merge.

[jmccormick7]

@cosmo0920 Do you mean #11011? That PR has the same changes pointed at master,. and has already been approved.

[cosmo0920]

@cosmo0920 Do you mean #11011? That PR has the same changes pointed at master,. and has already been approved.

Before merging backporting branches, we need to handle to process reviewing on development branch. In this case, we need to process #11011 which is targeted for master branch which is for v5.0 development at first.

[jmccormick7]

@cosmo0920 Do you mean #11011? That PR has the same changes pointed at master,. and has already been approved.

Before merging backporting branches, we need to handle to process reviewing on development branch. In this case, we need to process #11011 which is targeted for master branch which is for v5.0 development at first.

Makes sense, let me know if there's anything I can do to help with that effort or speed this along!

[jmccormick7]

@cosmo0920 Any updates regarding getting this merged?

[edsiper]

running CI.

So, can we process and merge #9735 at first, @edsiper? For me, that PR is good enough to merge.

@cosmo0920 running some checks on #9735, note that one will go in master. Is this PR intended to be part of 4.2 as well ?

[jmccormick7]

running CI.

So, can we process and merge #9735 at first, @edsiper? For me, that PR is good enough to merge.

@cosmo0920 running some checks on #9735, note that one will go in master. Is this PR intended to be part of 4.2 as well ?

@edsiper I think he meant #11011 which was the pr to master that this mirrors to the backport.

#9735 has the same feature intention, but differs in implementation to #11011 and this PR. @cosmo0920 had approved #11011, but it has yet to be processed for merge to master.