Hi Bram, I thought the WIKI page http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant+Use+Cases described the use cases that the platform is going to support. If you say "it's up to the application to implement it", the platform must by design support it and be able to tell me how to implement it. If the answer is that that is not the concern of the platform, that's the same as saying you do not support these use cases. I think the following Use Cases are crucial for using Amdatu in combination with Cassandra:
Use case 5 (MT-UC5): As a developer, I want to be able to add/remove tenants on the go. > Indeed, using Cassandra I want to create a new keyspace and associate it with > a new tenant and delete the tenant when it is deleted. Use case 9 (MT-UC9): As a developer, I want to be able to purge all platform-specific data of a (former) tenant without other influencing other tenants. > Yes, upon a purge I will delete the keyspace Use case 10 (MT-UC10): As a developer, I want to be able to migrate a tenant from one container to another > In a Cassandra cluster there is no way you can have a different set of > keyspaces per node. You could have several clusters though, but a single > Cassandra node cannot join multiple clusters. In a Cassandra cluster the data > being stored is also not really associated with a physical machine; it's out > somewhere but it's up to Cassandra to decide where to store it (even data in > a single keyspace may distributed over several nodes). So this use case > doesn't make sense with Cassandra. However, if you're talking about data isolation and Cassandra, you should be able to define multiple Cassandra clusters, such that data within one cluster is 'isolated' from the other clusters. So the use case should be; " As a developer, I want to be able to migrate a tenant from one cluster to another". Use case 11 (MT-UC11): As a developer, I want to implement services that can be notified in case a tenant is created or destroyed. > If with 'destroyed' you mean 'deleted', then this is exactly what I need. So are these use cases supported by the platform and if so; how? Regards, Ivo -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: vrijdag 27 januari 2012 12:06 To: [email protected] Subject: Re: [Amdatu-developers] Amdatu Platform Multi-Tenancy model feedback/reviews wanted 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+Req > uirements [2] > http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant+Use > +Cases [3] > http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant+Des > ign _______________________________________________ > 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 _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
