Story (Required)

As a cluster admin trying to manage my deployment of Builds for Openshift OpenShift I want the operator and all of its operands installed in the "openshift-builds" namespace so that I can upgrade OpenShift Builds independently of other OpenShift operands.

<Describes high level purpose and goal for this story. Answers the questions: Who is impacted, what is it and why do we need it? How does it improve the customer’s experience?>

Background (Required)

<Describes the context or background related to this story>

OLM makes an assumption that all operators installed in a namespace should be updated/lifecycled as a group. When we released v1.0, the operator installed itself in the "openshift-operators" namespace, meaning Builds for OpenShift can only be lifecycled (i.e. upgraded) with the other operators in that namespace.

This is not how cluster admins want to do this in the real world - they want operators installed in separate namespaces so they can upgraded independently.

This KCS Article describes in detail the consequences of installing in the "openshift-operators" namespace, and how this should be worked around/addressed.

Open Questions

• Shipwright allows the upstream operator to install the build controllers/components in a separate namespace. How should we address this?
  • Deprecate this feature upstream?  - we have fixed namespace when the downstream operator is creating the ShipwrightBuild operator.
  • In our "downstream" operator, actively break this feature by denying the operator/operand permission to create namespaces?
• How will this impact BUILD-721 (upgrade from v1.0 to v1.1?). We should support upgrade if the customer installed in any namespace

Ref: https://sdk.operatorframework.io/docs/building-operators/golang/operator-scope/

Out of scope

<Defines what is not included in this story>

• Other operator experience improvements captured in BUILD-760
• Deprecate the feature upstream
• Upgrade behaviour for builds 1.0 to 1.1

Approach (Required)

<Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

• Add the operatorframework.io/suggested-namespace annotation to the CSV, with value "openshift-builds". Note - customers deploy in any namespace through the OpenShift Console.
• When the operator creates the ShipwrightBuild object, the "targetNamespace" field in the spec should match the namespace the operator is deployed in.

Dependencies

<Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

• BUILD-719 (bootstrap new operator)

Acceptance Criteria (Mandatory)

<Describe edge cases to consider when implementing the story and defining tests>

<Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

• Operator is installed in the "openshift-builds" namespace by default
• Add integration test to check that operator could ONLY be installed in the "openshift-builds" namespace
• Downstream installation docs updated to specify the namespace for deploying the operator.

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Story Estimated:

Eng: 1

docs: 2

QE: 5

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met