Discuss - Transitioning to Organization-based Catalogs for Enhanced Component Management

Cells blueprint

Add CI/CD catalog to features impacted by Cells (!129942 - merged)

Background

GitLab plan to introduce a new entity that is called organization

An Organization is the umbrella for one or multiple top-level Groups. Organizations are isolated from each other by default meaning that cross-Namespace features will only work for Namespaces that exist in a single Organization.

Current status

Our team has currently implemented a Namespace catalog concept.

  • This catalog is associated with a namespace, whether it's a personal namespace or a top-level group.
  • All published components linked to a namespace are available in its respective catalog.
  • The number of namespaces in an organization could potentially be the number of available catalogs.

This architecture was used since we didn't have a way to isolate and scope components to an individual organization.

Current plan (as of today)

  • Introducing an instance-wide catalog tailored for Self Managed customers.
  • Introducing an instance-wide catalog for .com, which will serve as a Community catalog

Proposal

With the introduction of the 'cells', there is an opportunity to enhance the Catalog experience for both self-managed and .com users. My proposal outlines the following key adjustments:

  1. Evolution of Namespace Catalog to Organization Catalog

Transform the existing Namespace catalog into an Organization catalog. This means that all published components nested beneath a specific organization would be grouped together to a single unified catalog. The visibility level of these components would be determined by user permissions. In essence, users would only have visibility of components hosted on projects they have access to. In the future, we can incorporate additional filtering options such as by namespace, group, project, etc.

  1. Extension of Instance-Wide Catalog to Organization Catalog

Similarly, the instance-wide catalog also transitions to an organization catalog. This alignment ensures consistency between instance-wide and namespace catalogs. The Organization catalog approach would serve as a unified solution catering to both self-managed and .com users.

Benefits:

  • Enhanced user experience Users will find it more intuitive to manage and access components within the context of their organization, streamlining their workflows.

  • Consistency aligning the instance-wide and namespace catalogs under the organization catalog framework will provide a seamless experience, from the implementation and user experience side.

  • Scalability The organization-based approach accommodates growth, allowing for efficient component management even as the number of namespaces in organizations will grow.

Open question

The architecture of a community catalog remains an open question. An organization catalog might not be suitable for a community catalog, as it requires cross-organization visibility and search capabilities. Given that top-level Groups within an Organization can interact only within the same Organization, a public catalog would require a distinct architecture to enable broader interaction and search features.

Edited by Marcel Amirault