One example would be to allow for the processing of data from all devices connected to the system regardless of tenant, e.g. for keeping statistics or generic auditing etc.
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of Azhagappan Balasubramanian (INST/ECS4) <balasubramanian.azhagappan@xxxxxxxxxxxx>
Sent: Friday, March 31, 2017 14:36
To: hono-dev@xxxxxxxxxxx
Subject: Re: [hono-dev] Multi-Tenancy configuration in Qpid dispatch router
Hi Kai,
>> We use this approach so that receivers from arbitrary tenants can receive messages sent to arbitrary addresses.
I couldn’t imagine a use case for this. In my view, a tenant is more or less isolated from data perspective and why would one have a receiver to receive messages from multiple tenants?
Thanks.
Regards,
Bala
Hi Bala,
we are currently using Dispatch Router 0.7.0 which does not support the "multiTenant" property:
https://github.com/apache/qpid-dispatch/blob/0.7.x/python/qpid_dispatch/management/qdrouter.json
I have no idea what it is supposed to do and, consequently, do not know whether it would help to achieve what we need.
But thanks for the hint :-)
We are also currently not defining tenants per se but we only define groups for authorizing access to addresses (as you already found out).
Virtual hosts wouldn't help us FMPOV as the tenant information is encoded in the address of the messages. We use this approach so that receivers from arbitrary tenants can receive messages sent to arbitrary addresses. I do not think
that we could achieve this with using a virtual host per tenant because a receiver could then only receive messages that have been sent to the same virtual host that the receiver has connected to.
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
![](png50GqY_CVGY.png)
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> on behalf of Azhagappan Balasubramanian (INST/ECS4) <balasubramanian.azhagappan@xxxxxxxxxxxx>
Sent: Friday, March 31, 2017 12:35
To: hono-dev@xxxxxxxxxxx
Subject: [hono-dev] Multi-Tenancy configuration in Qpid dispatch router
Hi There,
I have a question regarding the multi-tenant configuration in Hono’s Qpid dispatch router. Currently tenants like
DEFAULT_TENANT, anotherTenant are configured as Groups within the broker’s virtual host „hono“.
As far as I could see there are also other ways to configure like
-
A separate virtual host for each tenant
- The Qpid listener also a multi-tenant boolean flag that can be configured in qdrouterd.json - https://github.com/apache/qpid-dispatch/blob/master/python/qpid_dispatch/management/qdrouter.json#L665
(not sure how the tenants can be configured after that but still interesting to find out)
There must a reason why the multi-tenancy was done differently in Qpid dispatch router than the obvious choice like separate virtual hosts. Can any one point me in the right direction
to find it?
|