This document is a work-in-progress and represents a very early state of the Pods design. Significant aspects are not documented, though we expect to add them in the future. This is one possible architecture for Pods, and we intend to contrast this with alternatives before deciding which approach to implement. This documentation will be kept even if we decide not to implement this so that we can document the reasons for not choosing this approach.
Pods: Organizations
One of the major designs of Pods architecture is strong isolation between Groups. Organizations as described by this blueprint provides a way to have plausible UX for joining together many Groups that are isolated from the rest of systems.
1. Definition
Pods do require that all groups and projects of a single organization can only be stored on a single Pod since a Pod can only access data that it holds locally and has very limited capabilities to read information from other Pods.
Pods with Organizations do require strong isolation between organizations.
It will have significant implications on various user-facing features, like Todos, dropdowns allowing to select projects, references to other issues or projects, or any other social functions present at GitLab. Today those functions were able to reference anything in the whole system. With the introduction of organizations such will be forbidden.
This problem definition aims to answer effort and implications required to add strong isolation between organizations to the system. Including features affected and their data processing flow. The purpose is to ensure that our solution when implemented consistently avoids data leakage between organizations residing on a single Pod.