Candlepin design doc: https://docs.google.com/document/d/10nEzXc87D2rKJjoi3MeX1N4BGZ6c6EkwOii9cayMLDo/edit

Draft design: Multiple Content Views - Google Docs

Goal:

• Build on the Hammer-only work in Part 1
• Extend DB models, API, and Hammer to work with Activation keys as well as hosts
• For web UI - This epic only covers displaying information about multi-CV hosts. It does not cover changing or assigning multiple content views.
• At the completion of this epic, the feature will
  • be fully coherent
  • deliver real customer value
•  

Acceptance Criteria:

As a user,

• I can assign multiple content view environments to an activation key via API & Hammer
• I can view activation keys that have multiple content view environments in Hammer
• I can view activation keys that have multiple content view environments in the web UI
• I am unable to assign content view environments to AKs via web UI. Instead, I am informed I must (temporarily) use API or Hammer
• I can view a list of all available content view environments for an org (in Candlepin name format) via Hammer & API
  • Via passing a param, I can filter CVEs by content view or LCE
• The order of content view environments on an AK is preserved, and hosts get registered to environments in the same order as on the AK
• Hosts registered with subscription-manager with multi-environment activation keys register with no errors (if allow_multiple_content_views Setting is enabled), and get assigned multiple content view environments
• Hosts registered with global registration with multi-environment activation keys register with no errors (if allow_multiple_content_views Setting is enabled), and get assigned multiple content view environments
• Hosts registered with multiple activation keys will continue to have the same logic applied - the last activation key that contains any content view environment(s) "wins"
  • See https://github.com/Katello/katello/pull/11135#discussion_r1750791759 
• When registering with multiple AKs, the content view environments of the multi-environment AKs are combined when registering
• When registering with multiple AKs and allow_multiple_content_views is disabled, AKs follow the previous behavior (the host is assigned the CV & LCE of the last AK with a CV/LCE)
• When registering with multiple AKs and allow_multiple_content_views is disabled, registration will fail if any of the AKs is a multi-environment AK.
• Required QE automation is in place for all acceptance criteria

Open questions:

Should we alter multi-AK logic to allow users to combine the CVEs of multiple AKs when registering? - Possibly can add this later, if it turns out to be a common enough use case. Yes, Partha added this if allow_multiple_content_views is turned on.

Cleanup & loose ends from Part 1:

• Applicability and repository ordering - QE can decide whether to do manual testing or automation
• Validations - We decided not to add these:
  • Prevent a user from assigning the same content view in multiple environments - Candlepin doesn't care. Would there be use cases for this?
  • If Library is the first content view environment, this is equivalent to Library being the only content view environment. Should we validate as such?
• Documentation:
  • Should document existing features upstream-only, so there's less documentation work in the next release
  • Document how it handles ordering and repository conflicts
    • when to use composite CVs (package conflicts) vs. multiCV (repo conflicts)

Old doc - Story Points: Multiple Env stories - Google Sheets

Old estimates

Documentation:

  release note - 2

QE:

 Story points - 10

Dev:

  Store points - 9