Hi folks,
Sorry for the late reply, I was on a work business trip and struggled to
get time to answer to this thread.
This gave a bit of time to:
- realize that multiple visions of what a tenant is exists
- getting multi-tenancy is more of a Linagora need that a community need.
Regarding Matthieu and Jean reaction, that I understand, I think it
would lead to a painful, over thousand of lines refactoring that I, and
people working with me at Linagora, would fail deliver.
I thought we could have been pushing an incremental, quick win, change
on the topic, but understand it could harm later refactoring, if any.
As such, I believe it would be easily possible to keep this
"multi-tenancy" topic in-house and part of Twake Mail, thus not annoying
nor pushing constraints to the community.
Would this make sense?
Few remarks inlined.
Best regards,
Benoit
On 06/11/2024 12:07, Matthieu Baechler wrote:
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 ?
The overall approach was to be pragmatic and deliver "multi-tenancy at
rest".
During the transit, all mails are bundled together and go through the
same mailet container.
Only once it is stored is it handled in a multi-tenant aware fashion.
As such we (at Linagora) focuses on multi-tenancy of the mailbox - again
we-linagora have a MDA centered vision of James.
(This is indeed very linked to our vision of multi-tenant SaaS offer)
Blob store thus is critical as it holds the content: getting this
multi-tenant first is indeed critical.
Metadata of Postgres application can be turned multi-tenant to with Row
level security.
James can handle multiple domains as long as you don't need to do TLS/SSL
or DKIM properly.
This depends: indeed people concerned about multi-tenancy of email
transit would need such features.
Got the point (and I agree) that per domain DKIM signing keys would be nice.
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.
Apache James took originally another direction
CF https://issues.apache.org/jira/browse/MAILBOX-318 in 2017
This approach have the benefit of not adding yet another concept,and
even trivial can go a long way. I must confess, at least for LINAGORA
topics I do think in this confortable canvas.
Concerns related to this simplification where raised in
https://www.mail-archive.com/server-dev@james.apache.org/msg74585.html
and again I am not against making this overridable / configurable.
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 ...
This lies down to the goals.
The goal I do have is to provide a backup to the ACL systems and ensure
that if bob reads alice emails because of a bug, at least they are on
the same domain.
(Think airbag in addition of seat belt)
With such a goal, and with the scope of the mailbox, only storage
interfaces like blob store would have needed adaptations, as domain
could be infered for existing 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.
Maybe that's a major difference here: I believe there are some
intermediary steps, that without providing 100% confidence in isolation
still delivers value and could be easily achievable.
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
