Organizations ADR 004: Organizationパススコープ
コンテキスト
既存の製品では、現在のOrganizationコンテキストを常に特定できるわけではありません。現在のシステムを変更してOrganizationsを適切に名前空間化する必要があります。
決定
パスベースのOrganizationスコープを実装することにしました。具体的には、Organizationルートにoのプレフィックスを付けます。
https://gitlab.com/o/my-organization/my-group/my-project/-/issues/1234
後方互換性を確保するために既存のルートを維持します。
Default OrganizationはOrganizationパススコープ内で表現されません。これにより、Self ManagedやDedicatedのような単一OrganizationインストールはパスNを冗長にしなくて済みます。
RESTおよびGraphQLリクエストは/api/v4および/api/graphqlのままとし、Organizationはorganization-idパラメーターで指定されます。
結果
- 後方互換性を確保するために既存のすべてのルートは維持されます。
- Organizationルートは
/o/スコープ内に存在します。 - RESTおよびGraphQLルートは現状のままとし、
organization_idは既存の方法で提供されます。 oはGroupまたはUserには使用できません。- オンプレミスで
oが使用されている場合、モデルバリデーションでOrganizationの作成が失敗し、oを解放するよう要求されます。 - マッピングの詳細を説明するデシジョンツリーがあります。
代替案
セグメンテーションの代替案
Organization識別の代替手段が包括的なスプレッドシートに詳細が記載されています。
スプレッドシート内の項目のうち、カスタムサブドメインが次に近い候補でしたが、いくつかの問題がありました。
- この機能をテナントレベルで製品に組み込む必要があります。現在はインスタンスレベルの機能です。
- このスキームは私たちの一部のサービスと互換性がありませんでした。例えば、SSHはホスト名でOrganizationを判断できず、ユーザー名などの別の識別子が必要になります。
- Default Organizationから独自のOrganizationに昇格したOrganizationsは、何らかのハイブリッドドメインアプローチなしでは後方互換性を維持できません。
- 別のホスト名を使用する場合、隣接サービス用のサブドメインを追加する必要があります。
- 他にも多くの懸念点がありました。
スコーピング識別子
o/は入力可能な識別子です。
oの他に、チルダ（~）記号も検討されました。これはすべてのGitLabサービスと互換性があり、URLスコーピングメカニズムとして多少の歴史的前例があります。しかし、~文字は技術に不慣れなユーザーには混乱を招く可能性があり、モバイルデバイスや一部のキーボードでは入力が難しいため却下されました。
/orgs/や/-/organizations/などの他の選択肢も却下されました。
