Create kustomization.yaml

[aminmokhtari94]

use case

install Kustomization from fluxcd GitRepository

---
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: strimzi-mqtt-bridge
spec:
  interval: 12h
  url: https://github.com/RahkarSanat/strimzi-mqtt-bridge
  ref:
    branch: main
  ignore: |-
    # exclude all
    /*
    # include install directory
    !/packaging/install
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: strimzi-mqtt-bridge
spec:
  interval: 1h
  targetNamespace: abrso-app
  sourceRef:
    kind: GitRepository
    name: strimzi-mqtt-bridge
  path: "./packaging/install"
  prune: true
  timeout: 1m
  patches:
    - patch: |
        - op: replace
          path: /data
          value: 
            application.properties: |
              #Bridge related settings
              bridge.id=abrso-bridge
           
              #MQTT server common
              mqtt.host=0.0.0.0
              mqtt.port=1883
              #Apache Kafka common
              kafka.bootstrap.servers=abrso-cluster-kafka-bootstrap.abrso-kafka.svc:9092
            topic-mapping-rules.json: |
              [
               ....
              ]
            log4j2.properties: |
              name=MqttBridgeConfig
              appender.console.type=Console
              appender.console.name=STDOUT
              appender.console.layout.type=PatternLayout
              appender.console.layout.pattern=%d{yyyy-MM-dd HH:mm:ss} %-5p [%t] %c{1}:%L - %m%n
              rootLogger.level=INFO
              rootLogger.appenderRefs=console
              rootLogger.appenderRef.console.ref=STDOUT
              rootLogger.additivity=false
              logger.bridge.name=io.strimzi.kafka.bridge.mqtt
              logger.bridge.level=INFO
              logger.bridge.appenderRefs=console
              logger.bridge.appenderRef.console.ref=STDOUT
              logger.bridge.additivity=false
      target:
        kind: ConfigMap
        name: mqtt-bridge-config

[scholzj]

Thanks for the PR. I leave it to @ppatierno to decide. But we in general do not support kustomize in our installation files as it interferes with other instalation methods. (e.g. kubectl apply -f as the simplest one).

[ppatierno]

Yeah I agree with Jakub. All the Strimzi components don't have support for a specific tool like kustomize and I think it's better to stay this way to not interfere with others.

[aminmokhtari94]

All right. Why don't you support Helm for this component?

[scholzj]

We do have Helm Charts for most components. So having Helm Chart for this would be fine. But so far:

• Nobody wrote it / contributed it. If you would want to contribute that, I guess it can be done similarly to for example Added helm chart drain-cleaner#62
• There is not yet any release. I wonder if there should be some release plan before investing the effort into Helm Chart as without a release it is probably not that useful.

[ppatierno]

While I agree with what Jakub said, let me also add that anyway we don't have Helm charts for the HTTP - Kafka bridge.
It's mainly because the bridge is well integrated in the Strimzi operator so we don't have any other way to install it on Kubernetes if not through the operator itself.
If we add Helm charts here, should we then having Helm charts for the HTTP - Kafka bridge as well? What's your take on this @scholzj ?

[scholzj]

While I agree with what Jakub said, let me also add that anyway we don't have Helm charts for the HTTP - Kafka bridge. It's mainly because the bridge is well integrated in the Strimzi operator so we don't have any other way to install it on Kubernetes if not through the operator itself. If we add Helm charts here, should we then having Helm charts for the HTTP - Kafka bridge as well? What's your take on this @scholzj ?

Well, we do not even have any Kubernetes deployment files for the Bridge IIRC because it is normally deployed through the operator (and the operator has a Helm Chart). But the problem is that we currently don't have any proper plan to what is next for the MQT bridge. That makes it hard to decide what is best. That is basically why I wonder if adding a Helm Chart now is the right time. If nothing else, it will not be pushed anywhere outside of this repo unless we do some release.

[scholzj]

That said, it is hard to get and keep any users without release and proper plans. So maybe that is something to think about. But I have no idea what might be missing etc. If the current state of features and bugs is reasonable, planning the first release should be probably next. And if @aminmokhtari94 or someone else would be willing to contribute a Helm Chart, it can help us get more feedback before we possibly integrate it into the operator one day.

[ppatierno]

This project is coming with the LFX mentoring program as a PCO and we haven't define a plan for a release yet.
If it's ready or not to be an MVP.
@aminmokhtari94 I was wondering what's the kind of usage are you thinking about for this? I am just curious, taking into account it's not released yet.

[aminmokhtari94]

@ppatierno
We are developing an FMS that sends data over MQTT and processes it through Kafka and Flink. The reason I use this tool is that I have not found any similar tool that performs topic mapping as effectively. This project works well for me :)

[aminmokhtari94]

@ppatierno
Also I want to note that we use emqx cluster for mqtt server, and egress topics data to strimzi-mqtt-broker. authentication & authorization, etc handled by emqx.

[ppatierno]

@aminmokhtari94 ...

We are developing an FMS that sends data over MQTT and processes it through Kafka and Flink. The reason I use this tool is that I have not found any similar tool that performs topic mapping as effectively. This project works well for me :)

I am glad to hear that :-)

Also I want to note that we use emqx cluster for mqtt server, and egress topics data to strimzi-mqtt-broker. authentication & authorization, etc handled by emqx.

So AFAIU your architecture has MQTT clients connecting to the emqx cluster to produce messages as well as subscribing to receive. But at the same time the emqx cluster is configured to connect as a producer against the Strimzi MQTT bridge to forward messages to Kafka? Is that right?

[aminmokhtari94]

@ppatierno
Yes. That's it.
for more informations: EMQX Bridge