You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2014/08/28 18:27:43 UTC
Tenant-specific OSGi configs (was: Multi-tenancy support in Sling - SLING-2656)
Hi,
On Thu, Aug 28, 2014 at 5:59 PM, Vineet <ta...@gmail.com> wrote:
> ...is there any
> support added to ConfigAdmin as well so that an osgi service could have
> different configurations for different tenants, just like we have based on
> run-modes?...
Not at this time.
It *might* be possible to use OSGi FindHook services to implement
this, so that services marked as being specific to a tenant are hidden
from other tenants, but that's just a wild idea at this point, and it
might have a lot of side effects (on admin tools, installer, etc.).
-Bertrand
Re: Tenant-specific OSGi configs (was: Multi-tenancy support in Sling
- SLING-2656)
Posted by David Bosschaert <da...@gmail.com>.
Hi Felix,
On 3 September 2014 05:04, Felix Meschberger <fm...@adobe.com> wrote:
> Hi
>
> Am 01.09.2014 um 01:07 schrieb David Bosschaert <da...@gmail.com>:
>
>> On 30 August 2014 08:36, Felix Meschberger <fm...@adobe.com> wrote:
>>> 2. OSGi Platform services have to be adapted as well. Particularly nasty probably are things like SCR and Blueprint which manage objects on behalf of bundles and must thus be knowledgeable of that situation maybe also by virtue of the MultieTenantActivator and the BundleContext wrappers.
>>
>>
>> Yes, I think in any kind of approach here platform services must be
>> aware of the multi-tenancy. One of the things that I have been
>> thinking about is to make OSGi Subsystems fully multi-tenant capable.
>> It still means that the platform services have to be 'subsystem-aware'
>> but at least this limits the awareness to one tenant-support API
>> instead of having to understand many different types of multi-tenant
>> solutions. Depending on your use case, today's OSGi Subsystems might
>> already be good enough.
>
> Would that mean we would have a subsystem per tenant ?
>
> If so, considering we have, say, 50 bundles to be made „multi-tenant-supporting“, it would mean would multiply 50 bundles by X tenants. So for 100 tenants we would have 100 subsystems with a total of 5000 bundles and class loaders ? Can/does that really scale ? I am scared.
I think it would mean a subsystem per tenant, but that subsystem may
not contain much code. With OSGi subsystems you can share code from
your parent subsystem. How much is shared is completely configurable
(with Composite Subsystems). Typically a subsystem would contain at
least one bundle but that bundle might just handle some configuration
and import the rest from its parent subsystem, if the code is all
shared. No need to be scared about that just yet ;)
> On the other hand, if tenants have differing sets of bundles, I agree that it might make sense to have subsystems per tenant. But this is another topic of multi tenancy, which involves resource allocation which we cannot handle in standard JVMs yet.
>
> Or, I may be completely off track ...
Bottom line is that this kind of setup hasn't really been tried much
yet AFAIK. I think subsystems can help here because of the fact that
they are standardized so that services such as EventAdmin/ConfigAdmin
if they are 'Subsystem Aware' can be re-used.
It might be useful to do a little experiment to see how well this
would work, but I think it should certainly not mean large amounts of
duplicated code :)
Cheers,
David
Re: Tenant-specific OSGi configs (was: Multi-tenancy support in Sling
- SLING-2656)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 01.09.2014 um 01:07 schrieb David Bosschaert <da...@gmail.com>:
> On 30 August 2014 08:36, Felix Meschberger <fm...@adobe.com> wrote:
>> 2. OSGi Platform services have to be adapted as well. Particularly nasty probably are things like SCR and Blueprint which manage objects on behalf of bundles and must thus be knowledgeable of that situation maybe also by virtue of the MultieTenantActivator and the BundleContext wrappers.
>
>
> Yes, I think in any kind of approach here platform services must be
> aware of the multi-tenancy. One of the things that I have been
> thinking about is to make OSGi Subsystems fully multi-tenant capable.
> It still means that the platform services have to be 'subsystem-aware'
> but at least this limits the awareness to one tenant-support API
> instead of having to understand many different types of multi-tenant
> solutions. Depending on your use case, today's OSGi Subsystems might
> already be good enough.
Would that mean we would have a subsystem per tenant ?
If so, considering we have, say, 50 bundles to be made „multi-tenant-supporting“, it would mean would multiply 50 bundles by X tenants. So for 100 tenants we would have 100 subsystems with a total of 5000 bundles and class loaders ? Can/does that really scale ? I am scared.
On the other hand, if tenants have differing sets of bundles, I agree that it might make sense to have subsystems per tenant. But this is another topic of multi tenancy, which involves resource allocation which we cannot handle in standard JVMs yet.
Or, I may be completely off track ...
Regards
Felix
>
> Best regards,
>
> David
Re: Tenant-specific OSGi configs (was: Multi-tenancy support in Sling
- SLING-2656)
Posted by David Bosschaert <da...@gmail.com>.
On 30 August 2014 08:36, Felix Meschberger <fm...@adobe.com> wrote:
> 2. OSGi Platform services have to be adapted as well. Particularly nasty probably are things like SCR and Blueprint which manage objects on behalf of bundles and must thus be knowledgeable of that situation maybe also by virtue of the MultieTenantActivator and the BundleContext wrappers.
Yes, I think in any kind of approach here platform services must be
aware of the multi-tenancy. One of the things that I have been
thinking about is to make OSGi Subsystems fully multi-tenant capable.
It still means that the platform services have to be 'subsystem-aware'
but at least this limits the awareness to one tenant-support API
instead of having to understand many different types of multi-tenant
solutions. Depending on your use case, today's OSGi Subsystems might
already be good enough.
Best regards,
David
Re: Tenant-specific OSGi configs (was: Multi-tenancy support in Sling
- SLING-2656)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Yes, it indeed sounds interesting, but I have two concerns (big ones ? not sure):
1. it uses Felix DependencyManager. Not a big deal, just an additional bundle
2. OSGi Platform services have to be adapted as well. Particularly nasty probably are things like SCR and Blueprint which manage objects on behalf of bundles and must thus be knowledgeable of that situation maybe also by virtue of the MultieTenantActivator and the BundleContext wrappers.
Regards
Felix
Am 30.08.2014 um 05:14 schrieb Alexander Klimetschek <ak...@adobe.com>:
> On 28.08.2014, at 16:19, Ben Fortuna <be...@gmail.com> wrote:
>
>> The amdatu project may also be useful for multi-tenancy at the bundle
>> level. I haven't used it personally but it looks interesting:
>>
>> http://amdatu.bitbucket.org/components/multitenancy.html
>
> Interesting! They actually allow running separate bundles for separate tenants and isolating them from each other. It definitely sounds like a good solution when you have different tenants licensing different "apps" and you want to shield them.
>
> The page above also talks about the separation between tenant and platform services - many services are better served global (example a logging service) and a first question is to identify what you would run as platform and what per tenant. It might also be a matter of performance - running many bundles per tenant might not be the best idea (don't know) and if you can handle the multi-tenancy within a shared bundle easily that would be less resource consuming.
>
> Cheers,
> Alex
>
Re: Tenant-specific OSGi configs (was: Multi-tenancy support in Sling
- SLING-2656)
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 28.08.2014, at 16:19, Ben Fortuna <be...@gmail.com> wrote:
> The amdatu project may also be useful for multi-tenancy at the bundle
> level. I haven't used it personally but it looks interesting:
>
> http://amdatu.bitbucket.org/components/multitenancy.html
Interesting! They actually allow running separate bundles for separate tenants and isolating them from each other. It definitely sounds like a good solution when you have different tenants licensing different "apps" and you want to shield them.
The page above also talks about the separation between tenant and platform services - many services are better served global (example a logging service) and a first question is to identify what you would run as platform and what per tenant. It might also be a matter of performance - running many bundles per tenant might not be the best idea (don't know) and if you can handle the multi-tenancy within a shared bundle easily that would be less resource consuming.
Cheers,
Alex
Re: Tenant-specific OSGi configs (was: Multi-tenancy support in Sling
- SLING-2656)
Posted by Ben Fortuna <be...@gmail.com>.
The amdatu project may also be useful for multi-tenancy at the bundle
level. I haven't used it personally but it looks interesting:
http://amdatu.bitbucket.org/components/multitenancy.html
Regards,
Ben
On 29 Aug 2014 02:27, "Bertrand Delacretaz" <bd...@apache.org> wrote:
> Hi,
>
> On Thu, Aug 28, 2014 at 5:59 PM, Vineet <ta...@gmail.com> wrote:
> > ...is there any
> > support added to ConfigAdmin as well so that an osgi service could have
> > different configurations for different tenants, just like we have based
> on
> > run-modes?...
>
> Not at this time.
>
> It *might* be possible to use OSGi FindHook services to implement
> this, so that services marked as being specific to a tenant are hidden
> from other tenants, but that's just a wild idea at this point, and it
> might have a lot of side effects (on admin tools, installer, etc.).
>
> -Bertrand
>