Feature Overview (aka. Goal Summary)  

OLM v1 will be enhanced with group-based management capabilities for packages, allowing users to treat related packages as a single unit, simplifying installation and updates similar to yum groupinstall and yum groupupdate.

Goals (aka. expected user outcomes)

• Simplify installation: Install and manage groups of related packages as a single unit, reducing manual effort and potential errors.

• Streamline updates: Update entire groups of packages and their dependencies with a single operation, ensuring consistent and coordinated updates.

• Enhance operational efficiency: Improve the maintainability and organization of complex deployments by grouping logically related packages.

Background:

OLM v0's approach to dependency management, while powerful, presented challenges with complex dependency graphs and unpredictable upgrade behavior.  To address these issues and provide a more streamlined, predictable user experience, OLM v1 is exploring a new dependency management concept. 

Inspired by tools like yum groupinstall and groupupdate, this approach aims to offer curated sets of related packages, simplifying common use cases while avoiding the complexities of fully automatic, arbitrary dependency resolution.  This will allow users to easily install and update groups of packages known to work well together, similar to how yum manages package groups.

Requirements (aka. Acceptance Criteria):

• Group definition: Provide a mechanism for defining and managing groups of Operator packages.
  • Operator packages can be assigned to groups using annotations or labels by the Operator package authors/providers.
  • Cluster admins can view the group membership of any package and list all Operator packages belonging to a specific group.
  • OLM v1 can detect and prevent circular group dependencies (e.g., Group A contains Operator package B, which depends on Group A).

• Group installation: Provide a mechanism to install all Operator packages within a specified group.
  • All Operator packages within the specified group are installed.
  • All dependencies of the Operator packages within the group are automatically resolved and installed.
  • Handle dependency conflicts during installation and provide clear error messages to show the conflict and potential resolution options.
  • The installation should be an atomic operation.  if any part of the installation fails, the entire process shall be reverted.

• Group updates: Provide a mechanism to update all Operator packages within a specified group (and their dependencies, if any).
  • All Operator packages within the specified group are updated to a user-specified target version.
  • Dependencies of the Operator packages within the group are updated as needed to maintain compatibility.
  • Handle dependency conflicts during the update process and provide clear error messages to show the conflict and potential resolution options.
  • The update process should be an atomic operation.  if any part of the update fails, the entire process shall be reverted.

• Configuration Customizations: Allow users to specify and manage configurations for each Operator package within a group.
  • Users can define parameters (e.g., environment variables, resource limits, tolerations, image tags, similar to Subscription config) that are passed to the Operator package during installation and updates.
  • Changes to configurations are applied correctly to the relevant Operator instances.

Documentation Considerations

• For Operator package authors/providers: Enable Operator package authors/providers to create, manage, and update Operator package groups.

• For cluster admins: Provide examples for installing/updating Operator package groups, and how to configure common package settings, including environment variables, resource limits, tolerations, and image tags.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

<your text here>

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

<your text here>

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

<your text here>

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

<your text here>

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>