Generate and store the deployment manifest in the repo

[rm3l]

/kind user-story

User Story

As a cluster administrator, I want to deploy the operator easily without having to clone the repo, So that I can get started and try it out quickly.

This is a follow-up to a discussion during one of the Working Group calls.

As suggested in #242 (comment), generating and storing the deployment manifest (outcome of make deployment-manifest) would allow people to install the operator with a one-liner command, like so:

kubectl apply -f https://raw.githubusercontent.com/janus-idp/operator/[branch|tag]/deploy/rhdh-operator.yaml

This also makes it easier to refer to the deployment manifests in the AKS/EKS/GKE docs.

Acceptance Criteria

• Just like with the bundle manifests (https://github.com/janus-idp/operator/tree/main/bundle/manifests), it should generate and store the deployment manifest in the repo, for example under ./deploy/rhdh-operator.yaml
• Just like with the bundle manifests (https://github.com/janus-idp/operator/blob/main/.github/workflows/pr-bundle-diff-checks.yaml), it should be enforced in CI that the deployment manifest is always updated
• (For later) We could generate a similar manifest for downstream RHDH and store those manifests under .rhdh/deploy/, such that it references the right downstream images

Links

• Related to Generate operator deployment script #241

/kind user-story

[gazarenkov]

This is what we discussed indeed ( https://issues.redhat.com/browse/RHIDP-1612 ) and approach is fine.
My concern is mostly about "just like bundle manifest approach"
Deployment manifest is a way to install operator w/o needs to clone project, alternative to OLM, Helm (which we do not have, just to mention).
So it has a real value for users which rather need to install "predictable/supportable" version than "arbitrary" state.
Also, as a maintainer of Operator I would prefer to deal with issue reports/requests containing concrete (supported) version and not arbitrary state downloaded from main branch any time.
I.e:
I am fine with storing deployment manifest files in github repo (this or some other) and have it downloadable using direct github url (no clone needed) as an installation option but it should be "released" manifests, i.e. the link like
https://raw.githubusercontent.com/janus-idp/operator/${VERSION}/deploy/rhdh-operator-[${VERSION}].yaml
is stable and points to released ${VERSION} of operator

[nickboldt]

Instead of supporting non-OLM installs of the operator, we can simply update the docs to clearly articulate that OLM is a prereq, with a link to where / how to install OLM. See RHIDP-2707

I suggest we close this and the associated JIRA https://issues.redhat.com/browse/RHIDP-1612 as "won't do" and simply focus on the doc change above.

[rm3l]

Instead of supporting non-OLM installs of the operator, we can simply update the docs to clearly articulate that OLM is a prereq, with a link to where / how to install OLM. See RHIDP-2707

From a downstream product perspective, it makes sense to focus on OLM as install method. But for the long-term vision of an upstream Backstage operator, I think we should not limit ourselves to only OLM.
But I agree we can close this one, since its goal was clearly for downstream RHDH usage. We can later on create specific issues if need be.

/close

[openshift-ci]

@rm3l: Closing this issue.

In response to this:

Instead of supporting non-OLM installs of the operator, we can simply update the docs to clearly articulate that OLM is a prereq, with a link to where / how to install OLM. See RHIDP-2707

From a downstream product perspective, it makes sense to focus on OLM as install method. But for the long-term vision of an upstream Backstage operator, I think we should not limit ourselves to only OLM.
But I agree we can close this one, since its goal was clearly for downstream RHDH usage. We can later on create specific issues if need be.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.