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" <g...@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 >>equivalent >> 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 >>multi-tenancy >> 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@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
