Azure with MQTT1 failover

[Harvie]

Hello, i've tried to setup azure mqtt with failover to secondary server (mqtt1) and it never switches from mqtt0.

I have working azure setup and i've as well added mqtt failover server like this:

  - ["mqtt1.enable", true]
  - ["mqtt1.server", "server.example.com"]

Then i've deliberately configured azure module to use wrong server hostname, which leads to MQTT0 tcp connect error (-14) every time. But MQTT1 is never even tried.

Use case is to failover to secondary azure server or self-hosted solution (like mosquitto) in case primary azure connection fails for some reason.

[rojer]

failover between azure and plain MQTT is not currently supported.

[Harvie]

And failover between two azure servers?

failover between azure and plain MQTT is not currently supported.

what if azure module configured the mqtt module using mgos_config_set_mqtt... that way it might work just as with any other mqtt connection.

[rojer]

it's possible, and fairly easy to do, actually. i'm just not sure how useful it is. are you already using it or is it just a hypothetical at this point?

[Harvie]

Well. I am going to deploy lots of mongoose OS devices connecting to XXXXXX.azure-devices.net and i will not have physical access to these devices after deployment. As i am not owner of the azure-devices.net domain, i have to be prepared for case that azure will eventualy change its hostnames (or otherwise change the provided service) without me being able to do OTA in advance.

I need devices to connect to alternate MQTT server on my own domain should that ever happen to maintain the communication.

I've tried to use my domain to point to azure iot hub using CNAME (so i can eventualy change the CNAME to point to my own MQTT server instead of azure), but that obviously causes certificate issues. And azure iot hub (unlike other azure services) can't be provided with custom certificate to run MQTT securely on custom domain (without using reverse proxy somewhere else).

[rojer]

sounds reasonable. as i said, it's not difficult to do, but no promises as to ETA.

[Harvie]

sure, hopefully azure iot hub will stay operational and unchanged for some time... but in a long run this might save my 4ss :-D

BTW this gets me thinking about how modules like this should play along... There are quite few questions considering the design choices. Eg.:

Would it make sense to have multiple parallel MQTT connections (each possibly with own failover alternative servers)?
Should azure module override the configuration of mqtt module?
Should there be more alternative slots than just MQTT0 and MQTT1? (...MQTTx)
Should azure and similar modules have their own slot on top of these (eg. MQTT0, MQTT1 and MQTT-AZURE)?
In case azure mqtt is used, should the failover be handled by azure module or mqtt module?
Will failover to self-hosted mqtt server (like mosquitto) break the azure module and cause disconnect or something? (eg. because there are some azure-specific features missing)

[rojer]

so, the recent refactoring was a step to having multiple simultaneous MQTT connections.
you can, in fact, do it today, just need to manage them manually - the API is described here, and the mqtt and mqtt1 config sections are in fact are simply used as arguments to mgos_mqtt_conn_create2.
you can construct your own config structure and create a connection, or, in fact, define mqtt2, 3, 4, 5... in your own config_schema similar to how mqtt1 is defined.
so you can have multiple connections today.

azure does not exclusively use the mqtt config section, it creates its own config based on settings from mqtt with key fields set from azure (here). so it's largely independent, and you can have independent connection defined in mqtt today and it will not interfere with azure.

for azure -> mqtt failover, it's up to the alternative server to provide service required by azure. most likely not full service, but just enough to recover the primary connection (i.e. probably rpc).

[Harvie]

the mqtt and mqtt1 config sections are in fact are simply used as arguments to mgos_mqtt_conn_create2.

Nice. This might be usefull.

most likely not full service, but just enough to recover the primary connection (i.e. probably rpc).

Yes. RPC's probably all i need to reconfigure azure/mqtt and possibly do OTA in case something changes.