hono tenant redirection mechanism

[bordeuax]

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

[ctron]

I think with the changes @dejanb just recently added to Hono, we might already have some parts of that now.

In EnMasse we needed to translate the tenant name to something unique. So we've been translating from tenant name, to a tenant id and continued using that internally. This might be close to what you need.

[bordeuax]

@ctron , @dejanb can you bring some reference to PR , issues or docs ; to have more info regarding changes mentioned above.

[dejanb]

@bordeuax It's TenantInformationService concept we added recently. If implemented, it is used to check if tenant exists before invoking any device registry operations.

TenantKey used here can be also extended to provide more information.

Take a look and let us know if that's something it might work for you.

[bordeuax]

@dejanb thanks for info. I checked TenantInformationService.java and is a great job ! But to fulfill my requirements we need to extend more; My final goal is to have Moved Permanently tenant code or logic in 3 places : Device registry, protocol adapters and North bound applications (business applications).

Device Registry

• 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 ?
• TenantInformationService.java check if the tenant exist or not , but what about when the tenant is disable "enabled": false?

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 ?

North bound applications - Business applications This topic maybe is beyond of Hono project scopes, but anyway 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.

[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.

[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 ...