[QUESTION] Running on bare-metal cluster & Metal-LB

[Sudokamikaze]

Hello fellow developers, everything works fine, except one thing. I'm using Metal-LB v0.8.1. Configuration map of metal-lb:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      -my_external_ip/32

As you've noticed, it's 32 mask up here, so I had to use shared IP annotation, here's the way I'm using it with Istio & Sitewhere

Istio:

tar -xvf istio-1.2.2-linux.tar.gz
cd istio-1.2.2
for i in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply -f $i; done
kubectl apply -f install/kubernetes/istio-demo.yaml
kubectl label namespace default istio-injection=enabled
kubectl annotate svc istio-ingressgateway metallb.universe.tf/allow-shared-ip=sitewhere-mosquitto --namespace istio-system```

Sitewhere:
```## Deploy Sitewhere
`helm install --name sitewhere \
--set sitewhere-infra-core.cp-kafka.persistence.storageClass=hostpath \
--set sitewhere-infra-core.cp-zookeeper.persistence.dataLogDirStorageClass=hostpath \
--set sitewhere-infra-database.mongodb.persistence.storageClass=hostpath \
--set sitewhere-infra-database.cassandra.persistence.storageClass=hostpath \
--set sitewhere-infra-database.influxdb.persistence.storageClass=hostpath \
sitewhere/sitewhere && kubectl annotate svc sitewhere-mosquitto-svc metallb.universe.tf/allow-shared-ip=sitewhere-mosquitto```

By NMAPing my external IP, I see that ports are opened, but when I do something with MQTT, there's no logs that something happened at sitewhere-event-sources

Should I buy another IP address or what might caused that behavior? Thanks in advance

[Sudokamikaze]

Here's the output from kubectl get pods:

sitewhere-mosquitto-svc             LoadBalancer   10.102.5.4       heres_my_ip   1883:30630/TCP                                 58s

String of istio gateway

istio-ingressgateway     LoadBalancer   10.110.130.90    heres_my_ip   15020:32115/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:31194/TCP,15030:30157/TCP,15031:30279/TCP,15032:30201/TCP,15443:31419/TCP   20d

[jorgevillaverde-sitewhere]

Hi @Sudokamikaze, thanks for your question.

My first recommendation would be that you have different IP Addressed for MQTT and Istio Ingress, but your set up seems to be correct. Are you able to connect and send messages to port 1883 using an MQTT client? If your answer is yes, we could check if those messages are getting into SiteWhere.

[Sudokamikaze]

I'm able to connect and send something

Current running pods:

sitewhere-asset-management-98657b47d-68fgz                    2/2     Running   0          143m
sitewhere-batch-operations-68dfcbf7b6-9khqb                   2/2     Running   0          143m
sitewhere-command-delivery-59675b7957-w5rdz                   2/2     Running   0          143m
sitewhere-cp-kafka-0                                          1/1     Running   0          143m
sitewhere-cp-kafka-1                                          1/1     Running   0          143m
sitewhere-cp-kafka-2                                          1/1     Running   0          143m
sitewhere-cp-zookeeper-0                                      1/1     Running   0          143m
sitewhere-cp-zookeeper-1                                      1/1     Running   0          143m
sitewhere-cp-zookeeper-2                                      1/1     Running   0          143m
sitewhere-device-management-858dd6988-thbcj                   2/2     Running   0          143m
sitewhere-device-registration-557fc87c59-6hlxg                2/2     Running   0          143m
sitewhere-device-state-7c55f9bc78-q4srb                       2/2     Running   0          143m
sitewhere-event-management-66c7d85c4-nv7hf                    2/2     Running   0          143m
sitewhere-event-search-697c58586-mwq9g                        2/2     Running   0          143m
sitewhere-event-sources-7b8b794cc9-gpbql                      2/2     Running   0          143m
sitewhere-inbound-processing-8bdc7c849-qcnjh                  2/2     Running   0          143m
sitewhere-instance-management-844d98c4b4-mz4r8                2/2     Running   0          143m
sitewhere-label-generation-59d879794-5wzhl                    2/2     Running   0          143m
sitewhere-mongodb-arbiter-0                                   1/1     Running   0          143m
sitewhere-mongodb-primary-0                                   1/1     Running   0          143m
sitewhere-mongodb-secondary-0                                 1/1     Running   0          143m
sitewhere-mosquitto-59997444c4-9lg6s                          1/1     Running   0          143m
sitewhere-outbound-connectors-cdb5f55d7-6cf54                 2/2     Running   0          143m
sitewhere-postgresql-0                                        1/1     Running   0          143m
sitewhere-rule-processing-66564db5c5-jtk2d                    2/2     Running   0          143m
sitewhere-schedule-management-7d856b5f8d-xddkj                2/2     Running   0          143m
sitewhere-streaming-media-6f8885d844-6prp8                    2/2     Running   0          143m
sitewhere-syncope-6d48899c56-49nnp                            1/1     Running   0          143m
sitewhere-syncope-console-796dc94c54-zsvr8                    1/1     Running   0          143m
sitewhere-syncope-enduser-64568b7f-cnftn                      1/1     Running   0          143m
sitewhere-web-rest-656d6d788c-w9lq6                           2/2     Running   0          143m

https://gist.github.com/Sudokamikaze/5e1150257c3edebd57528739c0862a13 logs I've took them by running:

kubectl logs sitewhere-event-sources-7b8b794cc9-gpbql -c sitewhere-event-sources

[derekadams]

We've had another report of events sent in via MQTT not being stored properly, so this may be a bug in the 2.1 images. I'll try to replicate the issue to see if something was broken during the transition to the 2.1 architecture. Just to verify, are you able to log in with the admin UI and add events via the device assignment emulator (or generally via Swagger/REST)?

[Sudokamikaze]

Oh, thanks for informing me!

Yeah, I'm able to log in via Admin application, tried to add something from Swagger - nothing happens & logs are not updates, just looks like there's no connection between them

[derekadams]

Yes, the REST APIs skip the event sources and inbound processing and store the events directly. If adding events works via the admin UI, but fails via MQTT, there is probably a bug in the event sources or inbound processing microservices.

[Sudokamikaze]

Thanks! Will report when I reach the installation

[Sudokamikaze]

Hi guys, sorry that I haven't updated you, now I'm out of installation, so will close the issue, if something happens - mention me here, I'd like to know the details later. Thanks!