To clarify my concerns, they are covered by these JIRA issues http://jira.amdatu.org/jira/browse/AMDATU-84 http://jira.amdatu.org/jira/browse/AMDATU-245 http://jira.amdatu.org/jira/browse/AMDATU-246
which are referred to by the container issue; http://jira.amdatu.org/jira/browse/AMDATU-247 This explains my concerns assuming that the 'current tenant' is always known by putting Amdatu services that are tenant unaware on a separate single-tenant container. This may be true for tenant unaware services on a single-tenant container, but we still need to resolve tenants on a multi-tenant container with tenant aware services. We might end up putting most/too many services (including the heavy ones like Shindig) on a separate container as they cannot be made tenant aware. Finally, it only solves the issue for tenants but not for any other context-related info, like the name of the logged in user. Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Ivo Ladage-van Doorn Sent: woensdag 5 januari 2011 10:12 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Multi-tenancy (and more) design I still have concerns regarding this approach, but I would like to explain my concerns face-to-face. Email doesn't seem to be the best channel for me, trying to express those concerns... Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Marcel Offermans Sent: woensdag 5 januari 2011 9:59 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Multi-tenancy (and more) design On 5 Jan 2011, at 8:48 , Mark Machielsen wrote: > Ok, after all discussion, I want to propose the following: > > Choice for multitenancy architecture: > - by default (and that's what we are going to promote) applications on top of > Amdatu are developed as tenantunaware > - such bundles are running in a tenant osgi container > - when there are good reasons (for example large services, like shindig) a > developer can decide to make the service tenant aware > - the service will be running in a tenant unaware container and will be > offered in the tenant container via remote services (in the service fabric > layer) Agreed. > We can however phase the implementation of the multitenancy concept. > > Proposal for 0.1: > - describe the multitenancy concept at the wiki Ok. > - leave the implementation for multitenancy to the current implementation: no > support for tenant unaware services in a tenant container, support for > tenantaware services I am not sure what you intend to say here. Can you clarify this a bit? Are you proposing not to implement the the proposal above for 0.1? > - plan the full multitenancy application in the roadmap Fair enough, if we all agree on the proposal above, we can start working towards it. > - implement the other items for 0.1: > - tenantaware useradmin: this is possible with the current implementation we > use by adding an adapter (according to Bram) Probably, but why not simply deploy a default User Admin implementation in each tenant container? > - Cluster support and backup support for Cassandra Sounds like a big one! > - JIRA mandatory issues Did we already tag those? Greetings, Marcel _______________________________________________ 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
