hono tenant redirection mechanism

What would you like to be added: In Hono Tenant API we have a mechanism that indicate tenant status "enabled": true, why not to extend or add something similar that will indicate that the tenant have been Moved Permanently (similar with HTTP redirects) and this status will be converted by protocols adapters into specific protocol implementation. For CoAp, AMQP and HTTP based protocol this should be feasible but I am not sure for current version of MQTT.

Why is this needed: The operation of IoT platforms in production some time requires for some special operation, for example:

• to move one tenant from one cluster to other cluster.
• migrate the tenant inside the same cluster to a different Hono version that is served on different URL or port.

/kind feature

[sophokles73]

I agree that having the ability to (re-)direct a device to a proper endpoint would be helpful. I would, however, tend to see this in the context of the more general problem of bootstrapping devices. The particular scenario pointed out by @bordeuax in this issue is reasonable and valid. I wonder, though, if we are not facing the same problem when a device’s credentials have expired or when a device is started up for the very first time and doesn’t really know yet, where to connect to. In all these cases we need to provision the device with (new) credentials and/or the endpoint address it should connect to. Thus, FMPOV we should discuss this problem and its potential solution in the context of #1807 instead of implementing a separate mechanism here. I also would rather use the message payload to convey provisioning information to devices than trying to fit it into (non-existing) meta-data properties of the particular device protocols in order to make the overall approach more consistent and easier to maintain. Devices would need to support such a mechanism in any case anyway …

[dejanb]

• IMHO we need to extend TenantKey.java and have the possibility to add some value or a lists of <key, value>. Because for code 308 we need also to communicate the URL that client should used for redirect. WDYT ?

We used to extend TenantKey to add more structure to it. But the idea of adding bag of properties sounds good to me as well. I need to revisit this anyway soon, so I’ll see to implement it this way.

• TenantInformationService.java check if the tenant exist or not , but what about when the tenant is disable "enabled": false?

In the rest of Hono code these two conditions are the same, so I don’t see much need for the distinction there.

Protocol adapters Protocol adapter still using a boolean flag for tenant status "enabled": true. WDYT about the possibility to have instead of "enabled": true something like TenantKey.java ?

Instead of doing this, I would recommend we add a new status (301) and provide a new URI in the body (in the similar way of how HTTP works. However, this will lead to the Tenant API change so we might need to do it 2.0.

@sophokles73 any thought on this?

North bound applications - Business applications This topic maybe is beyond of Hono project scopes, but any why if some one have already experience with EnMasse project and know how to send AMQP Redirect, I will be very glad with any shared info.

I’ll look into this and let you know, but this might be more appropriate topic for enmasse project.