Hi Bram, While working on the gadget container server at Amazon and a tenant mgmt gadget, I ran into one issue we need to think about. Currently, the Cassandra storage providers are tenant aware and the Cassandra PM will create a new keyspace automatically when a storage provider for a new tenant comes available. This is done by an implicit mapping of the tenant id onto the keyspace id. Now this becomes an issue when you want to delete a tenant. After you deleted a tenant, the keyspace will still exist. So when you recreate the same tenant, a keyspace with that id already exists which obviously leads to conflicts. But even worse, after deleting a tenant the UserAdmin service for that tenant keeps running. As the keyspace is not removed, the useradmin storage provider for that keyspace keeps running. UserAdmin is not an adapter of Tenant, but an instance exists for each available storage provider and therefore also keeps running. So we need to think about a solution for this, and other storage implementations (fs store will have similar issues). More generally, we might need to think about backups of deleted tenants and restore options.
Regards, Ivo -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: woensdag 23 november 2011 14:22 To: [email protected] Subject: [Amdatu-developers] Amdatu Platform 0.3.0 scope: Multi-Tenancy Hi List, Last week we had a Amdatu Platform PMC face-2-face where we have discussed the Multi-Tenancy design in depth. The design is being documented at the wiki [0] and the workbreakdown is in jira [1] under version 0.3.0 as we have decided that this should be the primary focus for this release. The very short version: 1) Change tenantmanagement to a ManageServiceFactory with metatype based configuration to prepare for provisioning. Remove already deprecated TenantmanagementServices. 2) Change multi-tenant model to be fully transparent and secure by providing tenant aware platform services (eg. ConfigurationAdmin) and managing service visibility per tenant. As a result this will enable: 1) Dynamically provision individual Tenants to one (or more) targets through te management Server 2) Apply "multi-tenant nature" to application code (custom and 3rd party) without affecting code. 3) Availability and reuse of standard compendium services in isolated tenant scope Note that this is still a single container model but is does open up the possibility for selective multi-container usage for use cases where we need this kind of isolation. Feel free to comment and we'de like your input on the design and further requirements for 0.3.0 scope. We expect the new design to be mostly backward compatible with what we have now although there will be recommended changes to existing code. Be ware that we will start moving stuff around soon. If you do not want to follow the entire refactor process we recommend staying on 0.2.1 until we give the all clear. Best Regards, Bram [0] http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant [1] http://jira.amdatu.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+AMDATU+AND+resolution+%3D+Unresolved+AND+fixVersion+%3D+%220.3.0%22+ORDER+BY+priority+DESC&mode=hide _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
