Hi Jan-Willem On Tue, Jan 31, 2012 at 11:39 AM, Jan Willem Janssen <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 1/31/12 11:07 AM, Bram de Kruijff wrote: >> Hi all, >> >> 2012/1/30 Marcel Offermans <[email protected]>: >>> >>> Some of us (including me) see a tenant as a logical entity that >>> (possibly) spans multiple nodes. So one can say "Tenant X is >>> deployed to nodes A, B, C". This allows applications (eg. Amdatu >>> Big Data) to use the tenant.pid as an identifying key when >>> creating a keyspace for Tenant X. This strategy is something we >>> will discourage in 1.0 but that is besides the point for now. >>> >>> >>> After a voice conference on Skype, Bram, Jan Willem and I just >>> agreed that the tenant.pid is globally unique and only of >>> interest to the Amdatu Platform and therefore cannot be used as >>> an identifying key of a storage mechanism of an application (see >>> the footnote below, or click >>> http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant+Design >>> if you don't want to scroll down (the yellow box is our summary >>> of this discussion)). Applications should use their own >>> configuration to configure the name of (in this case) a >>> keyspace. >> >> I'm just gonna go on record here. I send my reply on this thread >> after that call and said: >> >>> On Jan 30, 2012, at 12:51 , Bram de Kruijff wrote: >>> >>> Although the discussion about the exact meaning op tenant.pid not >>> yet finalized entirely it is very important to realize what >>> interpretation is being used by whom when they reply. So I >>> propose to explicitly mention whether you are talking about local >>> or distributed events. >> >> IMHO it is not finalized and there more I think about it I tend to >> disagree. I did agree to the fact stated by Jan-Willem that >> applications should not use it as on identifier but rather prefer >> their own configuration space. >> >> My concerns from two are two angels: >> >> 1) Why the tenant.pid should be globally unique? >> >> [snip] >> >> 2) Why the tenant.pid should NOT be globally unique? >> >> [snip] >> >> Bottomline, I do not believe we need a logical globally unique >> identifier. At least you have not shown me a concrete use case for >> it that can not be easily solved in another way. We may need a >> (generated) system identifier but we should not hijack and remove >> a higher level concept. > > We do agree on these two things: > 1) the tenant.pid should have *no* meaning whatsoever;
... to the application. It should not depend on it or use it as a key. > 2) the tenant.pid should be specified upfront. ... probably if you want to send it as config. The application doesn't care. > If we would say, as developers of a platform, that the tenant.pid > should be globally unique, it always gives you the advantage that this > property will be unique in *any* form of application that is built on > top of Amdatu. 1) Give me a concrete platform use case. Application developers can't use it. 2) The need for a unique identifier does not imply that tenant.pid must be it. > Additionally, making the tenant.pid really non-informative by making > it, for example, a GUID ensures that this property really stays > meaningless. I agree that a unique identifier should be generated. It is a system id. Not something users care about. > If a user of the Amdatu platform decides otherwise, he should also > deal with any problems that might occur. At least the platform > shouldn't be bothered by that... A user (application manager / system operator / etc) can't deal with it. He just thinks in logical constructs. Thinking about this I think we may come to a middle ground by reintroducing tenant.id. tenant.id := Logical identifier of a tenant (eg. "customerX"). Unique per node tenant.pid := System identifier of a tenant process (eg. "8237490832704hu-032uf2309"). Unique over all nodes grz Bram _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
