install.sh script does not work

[fjammes]

Bug Report

What did you do?

Run the following command against a fresh kind cluster:

curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.18.2/install.sh | bash -s v0.18.2

following install instructions of: https://operatorhub.io/operator/qserv-operator

What did you expect to see?

Successful install of OLM tools.

What did you see instead? Under which circumstances?

The script stop without installing anything and printing any error message.

Environment

• operator-lifecycle-manager version:
  v0.18.2

• Kubernetes version information:

kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:58:59Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"clean", BuildDate:"2021-01-21T01:11:42Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster kind:

kubectl get nodes
NAME                 STATUS   ROLES                  AGE   VERSION
kind-control-plane   Ready    control-plane,master   17m   v1.20.2

Possible Solution

Merge PR: #2218

Additional context
None

[timflannagan]

Potential duplicate of #2210 but I'm not sure whether a new tag was produced that contains those install script fixes.

[fjammes]

@timflannagan the script proposed on qserv-operator operatorHub webpage has not been fixed: https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.18.2/install.sh (see https://operatorhub.io/operator/qserv-operator). Could you please do it?

[timflannagan]

@fjammes I'm still waiting for that backport PR that fixes the install script in the v0.18.x branch to be approved/merged. I can ping someone on the team today to get the ball rolling again.

[timflannagan]

Alright the backport PR has merged - just waiting for a new z-stream tag to be created. Hopefully should be fixed by end of day.

[fjammes]

@timflannagan, thanks so much for your help. FYI it does not seem to work yet. I'm waiting for it to work before closing the issue.

[fjammes]

@timflannagan (ping @fritzm), this script has not been fixed yet: https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.18.2/install.sh? Could you please update it and let me know, this is blocking on my side, and this might also block other users.

[timflannagan]

I took a stab at getting the ball rolling by opening #2238. The current release process documents the need of bumping that file version first before we can cut a new z-stream release, so that PR needs to be merged.

[fjammes]

1. @timflannagan when do you plan to release v0.18.3 so that this bug is fixed?

2. This bug blocks most of operatorHub's operator install procedure because on operatorHub all install pages uses curl -sL https://github.com/operator-framework/operator-lifecycle-manager/releases/download/v0.18.2/install.sh | bash -s v0.18.2. So I am very surprised I am the only one to be blocked by this bug?

[timflannagan]

@fjammes I'm waiting on #2245 to be approved as it's blocking the v0.18.3 release #2244 PR.

[kingdonb]

For anyone else who was initially stumped by this, as was explained in #2210 before, the set -e at the top of the script causes it to abort and exit on error, because of this command:

kubectl get deployment olm-operator -n openshift-operator-lifecycle-manager -o=jsonpath='{.spec}' > /dev/null 2>&1
if [[ $? -eq 0 ]]; then
    echo "OLM is already installed in a different configuration. This is common if you are not running a vanilla Kubernetes cluster. Exiting..."
    exit 1
fi

which results in an error returning from kubectl get; you can work around it until the new version is released, by changing the line to:

kubectl get deployment olm-operator -n openshift-operator-lifecycle-manager -o=jsonpath='{.spec}' || /bin/true > /dev/null 2>&1

or simply removing the set -e at the top of the script.

[timflannagan]

Apologies for the slow turn around on this - we ran into some issues with the upstream release process (#2118 tracks streamlining that process). Closing this out as the v0.18.3 release has been cut and contains the installation script fixes.

[fjammes]

Thanks so much @timflannagan, it works fine now!