Re: Tenant-specific OSGi configs (was: Multi-tenancy support in Sling - SLING-2656)
Hi Felix, On 3 September 2014 05:04, Felix Meschberger wrote: > Hi > > Am 01.09.2014 um 01:07 schrieb David Bosschaert : > >> On 30 August 2014 08:36, Felix Meschberger 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)
Hi Am 01.09.2014 um 01:07 schrieb David Bosschaert : > On 30 August 2014 08:36, Felix Meschberger 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)
On 30 August 2014 08:36, Felix Meschberger 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)
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 : > On 28.08.2014, at 16:19, Ben Fortuna 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)
On 28.08.2014, at 16:19, Ben Fortuna 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)
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" wrote: > Hi, > > On Thu, Aug 28, 2014 at 5:59 PM, Vineet 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 >
Tenant-specific OSGi configs (was: Multi-tenancy support in Sling - SLING-2656)
Hi, On Thu, Aug 28, 2014 at 5:59 PM, Vineet 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
