-
Notifications
You must be signed in to change notification settings - Fork 14
Generate and store the deployment manifest in the repo #285
Comments
This is what we discussed indeed ( https://issues.redhat.com/browse/RHIDP-1612 ) and approach is fine. |
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. |
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. /close |
@rm3l: Closing this issue. In response to this:
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. |
/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
./deploy/rhdh-operator.yaml
.rhdh/deploy/
, such that it references the right downstream imagesLinks
/kind user-story
The text was updated successfully, but these errors were encountered: