[openstack-dev] [marconi] Reconsidering the unified API model
tomasz.janczuk at hp.com
Tue Jun 10 20:57:39 UTC 2014
Using processes to isolate tenants is certainly possible. There is a range
of isolation mechanisms that can be used, from VM level isolation
(basically a separate deployment of the broker per-tenant), to process
level isolation, to sub-process isolation. The higher the density the
lower the overall marginal cost of adding a tenant to the system, and
overall cost of operating it. From the cost perspective it is therefore
desired to provide sub-process multi-tenancy mechanism; at the same time
this is the most challenging approach.
On 6/10/14, 1:39 PM, "Gordon Sim" <gsim at redhat.com> wrote:
>On 06/10/2014 06:33 PM, Janczuk, Tomasz wrote:
>> From my perspective the key promise of Marconi is to provide a
>> *multi-tenant*,*HTTP* based queuing system. Think an OpenStack
>> of SQS or Azure Storage Queues.
>> As far as I know there are no off-the-shelve message brokers out these
>> that fit that bill.
>Indeed. The brokers I'm familiar with don't have multi-tenancy built
>into them. But rather than have one broker process support multiple
>tenants, wouldn't it be possible to just have separate processes (even
>separate containers) for each tenant?
>> Note that when I say ³multi-tenant² I don¹t mean just having
>> concept reflected in the APIs. The key aspect of the multi-tenancy is
>> security hardening against a variety of attacks absent in single-tenant
>> broker deployments. For example, an authenticated DOS attack.
>Understood, ensuring that one tenant is completely isolated from being
>impacted by anything another tenant might try to do.
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev