Add kafka oci image to cli env minimal

[obermeier]

Purpose

Currently, no messaging protocol implementation is configured in this environment.
As Kafka is currently the default protocol, Kafka and Zookeeper images are added to the configuration.

PR introduces (a) breaking change(s): no
PR introduces (a) deprecation(s): no

[dominikriemer]

Hi @obermeier the minimal image is intended to use MQTT as a message broker so that the StreamPipes installation is more lightweight. Is there a reason you want to use Kafka/Zookeeper with this setup and don't use one of the Kafka CLI profiles? Or do you think we should change something in the Kafka profiles?

[obermeier]

Hi @dominikriemer ,

thank you for this hint. The idear to integrate Kafka/Zookeeper was a bit hasty.
I appreciate the idea of adopting a more lightweight solution. For most use cases, utilizing Nats or MQTT seems to align better with the goal of efficiency and simplicity.

I forgot to configure the preferd protocol my attention was primarily focused on addressing an exception related to configuring pipeline elements, specifically the "Failed to create new KafkaAdminClient" error.

While writing the response, a question came to my mind.
Is it intended that StreamPipes automatically selects the most suitable protocol? The UI's recording list and the term "preferred protocol" seem to imply some level of automatic selection.

[dominikriemer]

Hi @obermeier well, that's a good question ;-)
I guess the short answer is it's supported, but incomplete.

Long answer:
The preferredProtocol can be defined at installation time as an environment variable. In the messaging settings in the UI, the prioritized protocols can be sorted. Any extension service can define its supportedProtocols (this can even be defined individually for each pipeline element). There can be one or more supported protocols. So when using the pipeline editor and connecting two pipeline elements, the system also checks for a protocol match. E.g., when you have two extension services with one service supporting NATS and Kafka and another service supporting Kafka, NATS and Pulsar, the system would select the protocol depending on the priority defined in the UI.

What makes this feature incomplete is that changes in the UI will only affect newly created pipelines. Existing pipelines use the protocol selected during pipeline creation. Feature completeness would be achieved by migrating all existing adapters and pipelines in case the protocol priority is changed.

I'm a bit unsure what to do with this feature:
On the one hand, it can be useful in the future when thinking of edge-cloud scenarios, e.g., pipelines with pipeline elements which exchange data over local nodes (which could be something lightweight like MQTT and NATS) and other pipeline elements supporting Kafka and Pulsar for more centralized, heavyweight processing.
On the other hand, removing the dynamic selection would simplify the system and selecting a global protocol at installation time would be permanent.

What do you think?

[obermeier]

Hi @dominikriemer,
thank you very much for the explanation. In my opinion, this is a very useful feature, especially for the examples which you mentioned!

Related to my misconfiguration, I think there is no change required, since the error is easy to detect and resolve