Hi folks, I definitely share the concerns Jean raised in his email.
We already have so many concepts that we are loosing most of the potential users and contributors before they even manage to do something useful with James. Multi-tenant is a very desirable feature, and I understand why a company making money hosting James would want that feature, but retrofiting such a concept into such a large codebase requires some planning. Would you agree to propose an ADR about that? We could then use the work done for the ADR to update the documentation. Some more comments below. On Wednesday, November 6th, 2024 at 06:44, Jean Helou <jhe...@apache.org> wrote: > Hello, > > I'm taking my evening to try and answer about this asking my questions. > Especially since I saw the PR is already being pushed forward and I am not > convinced by the design decisions that were made. > > > Today James does not support multi-tenancy for blob store. Therefore blob > > isolation between domains could be an issue for example in a SaaS > > deployment that requires strict data isolation for users. > > > Would you say that James supports multi-tenancy in other parts, why focus > on blob store ? > James can handle multiple domains as long as you don't need to do TLS/SSL > or DKIM properly. Is a domain the same thing as a tenant ? If yes why > introduce a new concept, if no what would you say is the > difference/relationship between a domain and a tenant ? Personally, I would expect a Tenant to be the uppermost segregation key. That way, a Tenant can have multiple Domains, which is a frequent usecase. > how do you expect the new concept to reflect in the various apis ? I guess this is the most important question. And we have so many APIs ... > Pulsar has a multi tenant > api that scopes all operations for instance. it is clearly a first class > concept. Should tenants also be a first class concept in james ? My take is: it should. > You propose to introduce another concept: `Bucket` which is composed of a > `BucketName` and an optional `Tenant`. > How does the Tenant relate to the `BucketName` ? shouldn't the tenant or > domain be a first class parameter of the storage apis instead ? > > The jira mentions > > > That way blobstore could implement different isolation strategies for > > tenants (configurable): > > > - buckets as today - good for few tenants after all.\ > > > Which suggests that one can already use the buckets to isolate > tenants/domains, this in turn suggests that the BucketName passed in the > BlobStore api today is already usable as a discriminant for tenants/domains > (though I have yet to find any uses of this with something other than the > default bucketname in the code). If BucketName is the current parameter to > isolate tenants shouldn't it be replaced by the new tenant concept instead > of adding another information ? How should a programmer decide when to use > which ? Tenant should never be optional. Each tenant should have its specific configuration, there's no reason to mix bucket concept in the code with tenant. > > Do we really need to propagate the domain/tenant concept to all the storage > apis ? Will it be necessary for the MailRepositories too for instance ? I don't see how you would have a proper tenant segregation if it's not propagated in each and every layer. > Overall, Isn't this change to introduce multi-tenancy large enough to > warrant an ADR if only to answer these questions and document the concepts > (possibly retrodocument them) 100% agree. Cheers, -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
