Hi again,
I just had a look into the service hooks available in R4.2
(http://www.osgi.org/javadoc/r4v42/org/osgi/framework/hooks/service/FindHook.html).
At this point I do not see how these could be used to solve our
problem. Most notably the FindHook provides a way of intercepting and
manipulting the results of a service lookup, but there is no way to
determine if it was a tenant aware service that initiated the
lookup...
public class TenantAwareFindHook implements FindHook {
public void find(BundleContext bundleContext, String className,
String filter, boolean allServices,
Collection /* <? extends ServiceReference> */serviceReferences) {
// I know which BundleContext does the lookup, but I have no
way of determining whether
// there is a tenant associated with it.
}
}
@All any thoughts?
@Marcel a while back you said that embedded containers where out and
hooks are in. Can you elaborate on why not to embed and what direction
the hooks are going. Are they working on new ones in the spec? Do you
have some links?
Regards,
Bram
On Tue, Dec 14, 2010 at 7:33 PM, Bram de Kruijff <bdekruijff at gmail.com>
wrote:
> Hi All,
>
> just wanna report I committed a poc for the multi (nested) container
> scenario into my sandbox. The poc (see readme below) shows a tenant
> aware useradmin (with multitenant storage) at the platform level. The
> tenantmanager (also a tenant aware) spawns a nested container for each
> tenant and publishes only(!) the relevant useradmin for that admin
> into this container along with a global logservice and some bundles
> that are 'tenant specific'.
>
> Pros:
> * relatively easy as-full-as-you-want isolation a tenants
> * a nice 'tenant lifecycle' and layer of indirection for manageability
> * tenant aware code only at platform layer. app developer need not worry
> * ...?
>
> Cons:
> * heavy(?) I got OOM at 500 tenant with 256M memory in poc setup
> * portable to other OSGi impl (?) Should be but needs factory.
> * ...?
>
> Obviously this is just a first poc and needs a lot more testing but in
> the meanwhile ?I'd like to hear your thoughts, pros and cons. ?I'd
> also like to create a poc using framework hooks to so we can properly
> evaluate the two solutions.
>
>
> Regards,
> Bram
>
>
> --------------------------------
> PoC for nested Tenant Management
> --------------------------------
>
> basic design:
>
>
> * TenantManager is a tenant aware service that
> ? ? ? ?1) spawns a new osgi container for each tenant registered
> ? ? ? ?2) delegates platform packages to the tenant container
> ? ? ? ?3) proxies (only relevant!) services (log/useradmin) to the tenant
> ? ? ? ?4) monitors container to take action (eg refresh)
> ? ? ? ?5) TODO: publishes tenant services in parent container (eg a REST
> service?)
>
> * This UserAdmin FS storage is now tenant aware that
> ? ? ? ?1) create a storage dir per tenant (based on id)
> ? ? ? ?2) leverages PAX user admin through extender pattern
>
> -> useradmin per tenant
> -> application dev model in tact
>
>
>
> implementation notes/todos:
>
> * set of delegated packages is static (should be extendable)
> * list proxied services is static (should be extendable)
> * currently deploys four bundles into each tenant container
> ? ? ? ?- Apache Felix Dependency Manager;
> ? ? ? ?- Apache Felix Dependency Manager Shell
> ? ? ? ?- Apache Felix Shell Service
> ? ? ? ?- Apache Felix Remote Shell
> ? ? ? ?- Amdatu UserAdmin Commands
> * currently proxies global logservice into each tenant container
> * currently proxies relevant useradmin into tenant container
> * JVM with Xmx=256 went OOM at about 500 tenants
>
>
> 1) Starting this up:
> ? ? ? ?* Copy the amdatu-tm folder into devserver layout
> ? ? ? ?* Copy startup from this folder to devserver root
> ? ? ? ?* startup
>
>
> 2) inside parent container
>
> ?-> tmcreate 245
> ?tmcreate <tenantId> <tenantName>
> ?-> tmcreate 245 jan
> ?-> tmlist
> ?'123' ? - 11
> ?'245' ? - jan
> ?-> tmdelete 123
> ?Tenant deleted: 123
>
> note: use integers for tenantid as it is used to register a remote
> shell on that port
> note: refresh in the parent container will restart all tenants
>
> 3) Inside tenant container
>
> ?* telnet 127.0.0.1 245
>
> ?Felix Remote Shell Console:
> ?============================
>
> ?-> ps
> ?START LEVEL 1
> ? ? ID ? State ? ? ? ? Level ?Name
> ?[ ? 0] [Active ? ? ] [ ? ?0] System Bundle (3.0.6)
> ?[ ? 1] [Resolved ? ] [ ? ?1] Apache Felix Dependency Manager (3.0.0.SNAPSHOT)
> ?[ ? 2] [Active ? ? ] [ ? ?1] Apache Felix Dependency Manager Shell
> (3.0.0.SNAPSHOT)
> ?[ ? 3] [Active ? ? ] [ ? ?1] Apache Felix Shell Service (1.4.2)
> ?[ ? 4] [Active ? ? ] [ ? ?1] Apache Felix Remote Shell (1.1.2)
> ?[ ? 5] [Active ? ? ] [ ? ?1] Amdatu UserAdmin Commands (0.1.0.SNAPSHOT)
>
> ?-> uacreate 123
> ?User created: 123
> ?-> ualist
> ?'123
> ?-> uadelete 123
> ?User deleted: 123
> ?->
>
>
>
> On Fri, Dec 10, 2010 at 3:25 PM, Bram de Kruijff <bdekruijff at gmail.com>
> wrote:
>> Hi Ivo,
>>
>> Good points, thanks. Please feel free to add things on the wiki. I'm on
>> mobile atm so just two quicks notes:
>>
>> I would not call the management server the provisioning server as
>> provisioning is only part of its responsibilities. On the other hand I do
>> like the notion of "provisioning a tenant onto a node"!
>>
>> The data sharing use case I would aproach as a data (web) service. Either
>> owned by one or even 3rd party. This removes the data sharing at the
>> platform level requirement, which I fear would be a swamp of complexity. At
>> the same time it opens up the data for reuse for any consumer on the web, so
>> its much more RESTfull.
>>
>> Enjoy the weekend!
>> Regards,
>> Bram
>>
>> On Dec 10, 2010 2:57 PM, "Ivo Ladage-van Doorn"
>> <Ivo.Ladage-vanDoorn at gxsoftware.com> wrote:
>>> Hi Bram,
>>>
>>> I think this is a good starting point for the multi-tenancy discussion.
>>> And of course I have some remarks/additions:
>>>
>>> Configuration, Management - I would think that the application should
>>> support configuration per tenant. For example, if one tenant decides to
>>> reduce the session timeout to 5 minutes, it should not affect the other
>>> tenants. Some configuration on the other hand might be shared among all
>>> tenants hosted by the same application and if so, should be read-only to
>>> them as changing it would affect other tenants.
>>> Regarding management; I think tenant management should be separated from
>>> the Amdatu runtime and managed by the provisioning server. The provisioning
>>> server needs to be tenant aware, as it should decide what tenants run on
>>> what nodes and if tenants run in isolates OSGi containers and/or VMs
>>> (dependent on their contract for example; gold contract = isolated container
>>> and VM). As a consequence a Tenant in the Amdatu runtime is read-only; it is
>>> managed by the provisioning server (which may, and probably will, run on the
>>> Amdatu platform).
>>>
>>> Sharing information - Some tenants will want to share content. Think of
>>> big publishers with multiple magazines. Each magazine would be a tenant, but
>>> they still want to share articles with each other. There could even be
>>> authorization involved; one tenant adds articles while other tenants can
>>> only read them and incorporate them into their website, but not change them.
>>>
>>> Licensing - Multiple tenants hosted by the same application may have
>>> different licenses. Dependent on their license, some
>>> services/functionality/content will or will not be available to them.
>>>
>>> Logging - I think logging should be separated, as each tenant would want
>>> to see only log entries that are relevant to them. More importantly, log
>>> files may contain information that are absolutely forbidden to be seen by
>>> others (as we experienced with some customers; we were not even allowed to
>>> read log files at all, they first has to be censured)
>>>
>>>
>>> Regards, Ivo
>>>
>>> -----Original Message-----
>>> From: amdatu-developers-bounces at amdatu.org
>>> [mailto:amdatu-developers-bounces at amdatu.org] On Behalf Of Bram de
>>> Kruijff
>>> Sent: vrijdag 10 december 2010 13:22
>>> To: amdatu-developers at amdatu.org
>>> Subject: [Amdatu-developers] Multi-tenancy (and more) design
>>>
>>> Hi all,
>>>
>>> I just created a mechanisms section under architecture on the wiki and
>>> have put down an initial analysis on multi-tenancy. IMHO we must
>>> address these concerns asap and I would appreciate you feedback and
>>> contributions :)
>>>
>>> Regards,
>>> Bram
>>>
>>> ps. http://www.amdatu.org/confluence/display/Amdatu/Principle+Mechanisms
>>> ps. Working on a proof of concept for embedded containers. In a
>>> sandbox near you soon.
>>> _______________________________________________
>>> Amdatu-developers mailing list
>>> Amdatu-developers at amdatu.org
>>> http://lists.amdatu.org/mailman/listinfo/amdatu-developers
>>>
>>> _______________________________________________
>>> Amdatu-developers mailing list
>>> Amdatu-developers at amdatu.org
>>> http://lists.amdatu.org/mailman/listinfo/amdatu-developers
>>
>
