SOME/IP input plugin

[anthonypayne-GM]

This change introduces a new input plugin, in_someip. This plugin is used to subscribe to events and capture notifications from a SOME/IP network. It also can be used in inject SOME/IP requests and capture the response to the data pipeline.

The input plugin uses an open source implementation of the SOME/IP stack, vsomeip. This library is used unchanged, but a wrapper library, libsomeip-c, exposing C-language APIs is part of the PR.

For reference to SOME/IP: protocol specification.

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.

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

Documentation

• [N/A ] Documentation required for this feature

Backporting

• [N/A] 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.

[anthonypayne-GM]

Example config file is included in the PR, conf/in_someip.conf:

[INPUT]
    Name someip
    Tag  in.someip

    # Events to subscribe to.
    # Each event should have form:
    #    Event <service id>,<instance id>,<event id>,<event group 1>,...
    #
    # Each event must have at least one event group
    Event 4,1,32768,1
    Event 4,1,32769,2

    # RPC to send on startup
    # Each RPC entry should have form:
    #    RPC <service id>,<instance id>,<method id>,<Request Payload>
    #
    # Request payload should be base64 encoded
    RPC   4,1,1,CgAQAw==

[anthonypayne-GM]

Debug log from runtime tests is attached.
rt_test.log

[anthonypayne-GM]

Output from valgrind:

[ OK ]
SUCCESS: All unit tests have passed.
==7910== 
==7910== HEAP SUMMARY:
==7910==     in use at exit: 5,741 bytes in 13 blocks
==7910==   total heap usage: 17,360 allocs, 17,347 frees, 5,723,214 bytes allocated
==7910== 
==7910== LEAK SUMMARY:
==7910==    definitely lost: 0 bytes in 0 blocks
==7910==    indirectly lost: 0 bytes in 0 blocks
==7910==      possibly lost: 0 bytes in 0 blocks
==7910==    still reachable: 5,741 bytes in 13 blocks
==7910==         suppressed: 0 bytes in 0 blocks
==7910== Rerun with --leak-check=full to see details of leaked memory
==7910== 
==7910== For lists of detected and suppressed errors, rerun with: -s
==7910== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[patrick-stephens]

Thanks for the contribution, I think we need to look at those runtime dependencies though at the very least - also do we need to include them in the target builds as well under ./packaging/distros?

I don't think we can realistically globally enable this for every supported target. It also seems to use C++ compilation and dependencies.

[patrick-stephens]

This is including the dev libraries in the runtime image - we should just have the minimal set of libraries needed for running fluent bit, not those for building it.

[patrick-stephens]

As above, do we really need the development libraries here or can we just use the runtime ones?

[patrick-stephens]

We're including these development libraries but not actually enabling the plugin itself - is that right?

[patrick-stephens]

Ah, we globally enabled it which may be an entirely separate issue.

[patrick-stephens]

Dependencies are generally vendored into the /lib directory and not fetched remotely.

[patrick-stephens]

I don't think you can enable this globally without considering all platforms that are supported including Windows and macOS configuration.

[patrick-stephens]

This seems to be a C++ file, is that just a standard example and/or can it be C only? It seems to require a C++ compiler by looking at the example cmake linkage.

[patrick-stephens]

For new plugins we must ensure it builds for all targets and CI so I've triggered that. It looks like we have a lot of failures around missing dependencies and the like in various places/platforms.