Hi Ivo, thanks for your feedback!
On Fri, Jan 27, 2012 at 9:38 AM, Ivo Ladage-van Doorn <[email protected]> wrote: > Hi Bram, > > As far as I can see, the use case I mentioned in november last year is not > fully covered. In the case of using Cassandra for storage (but same applies > to other storage implementations) we have a Cassandra keyspace associated > with one particular tenant. When a new tenant (service) comes available, we > add a keyspace if it does not yet exist. But in the current approach I don't > see anything that tells me the tenant has been deleted; there is no > difference between the tenant service being stopped and permanently removed. > The same question applies to creating backups for tenants. How can I > implement 'delete tenant' and 'backup tenant' features for my storage engine? > A full working code example with the new approach would be nice. I see the use-case but I am not sure we should/can address that at this level. As far as the mt model is concerned tenant come and go at will on any particular node and applications must deal with it. The delete/backup/purge semantics simply are not there. Remember that we are looking at a distributed model so I can not say purge on one node when the same may be active on another node. Having said so I am not 100% on where that responsibility lies and how to solve it. I think it is an application concern and maybe Big Data can help out (eg. a tenant agnostic separate tenant data reaper that can be told by configuration to purge a particular keyspace). Talking about backups that probably even would not cut it as an application may have more state than just a Big Data keyspace. Not saying that we could not provide an application model that provides this kind of application lifecycle constructs. I had similar concerns when I created issue AMDATU-325 a while back. I do however believe it is not a concern that should be handled by the (low level) mt mechanism. Best Regards, Bram > Regards, Ivo > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Bram de Kruijff > Sent: woensdag 25 januari 2012 20:22 > To: [email protected]; [email protected] > Subject: [Amdatu-developers] Amdatu Platform Multi-Tenancy model > feedback/reviews wanted > > Hi list, > > over the last week we have been working on a revised Multi-Tenancy model for > Amdatu Platform 1.0. This included (partially offline) discussions on what we > will and wont cover as well as how we will implement it. In a nutshell, > comparing to the "old"model the goal is to come up with a solution that is > optional, transparent/non invasive, still very flexible and ready for > provisioning. The results are covered in the pages listed below providing an > architectural overview [0], requirements [1], use-cases [2] and a more > detailed design[3]. > > This is not the end and it is not a done deal as over the next couple of > weeks we will spend some more iterations to refine, implement and proof the > model. Therefore at this point we would very much appreciate feedback from > the community and specifically anyone interested in Multi-Tenancy. Do you > feel requirements and use cases cover your needs? Do the design and proposed > implementation make sense? Any feedback will be most valuable to our end > goal, which is to come up with a stable future proof model for 1.0! > > Thanks and greetz, > Bram > > [0] http://www.amdatu.org/confluence/display/Amdatu/Multi-tenancy > [1] > http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant+Requirements > [2] > http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant+Use+Cases > [3] http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant+Design > _______________________________________________ > 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 _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
