Skip to content

Size: M - [Feature] Cells 1.0 impact for email ingestion

Email routing will be another interesting feature. I imagine the routing itself may sit at the cluster level, whereas the actual logic would be at the cell level to actually perform the work (e.g. reply to a comment)

See:

From Mail room for Cells (gitlab-com/gl-infra/production-engineering#25087 - closed):

See (Size: S to M) - Cells - Workflow: Ingest emails (&13213)

Overview

GitLab offers incoming email where users can create issues, patches, and service desk by having a unique email address per project, for example, incoming+SOME_ID-issue@incoming.gitlab.com, then emails are processed by mail_room so that it creates issues, and other features (this is my understanding, please correct it if it's wrong).

With Cells we plan to have multiple isolated GitLab instances. This means that we are going to multiple multiple mail_room queued processing the same email, and the project might not even exist in that cell.

image

source

Possible Problems

  1. Having multiple mail_room processes might read an email and doesn't process it.
    • This might not be a problem because each handler seems to validate if the project exists.
  2. Having a single incoming inbox for all cells will reduce reliability.

Possible Options

  1. A mailbox per Cell
    • We need to keep in mind in the future we want to have the ability to move the organization from 1 cell to another, this means that the email address will end up changing every time we move the organization which is a breaking change to our users.
  2. Single mailbox, multiple mail_room only processes emails for the projects they have access to.
Edited by Marc Saleiko