Update Process Question

[msfrucht]

Type of question

Community Best Practices

Question

What is the process of updating OLM from one version to another? The install.sh script will refuse to run if an existing OLM install is detected?

Environment

• Kubernetes from scratch

OLM Release: 19.1

kubectl get csv -n olm NAME DISPLAY VERSION REPLACES PHASE cert-manager.v1.6.1 cert-manager 1.6.1 Succeeded packageserver Package Server 0.19.1 Succeeded

Would like to upgrade to OLM 20.0.

• Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:41:28Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:35:25Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster kind:
• On-prem, not cloud

Additional context Ask if any other context is needed.

[exdx]

Hi @msfrucht, it should be safe to use the existing install.sh script to upgrade OLM in-place, since it uses kubectl apply semantics under the hood it should process the update safely (enough)

In the long run, we are interested in packaging OLM and self-deploying it, so that any OLM upgrade comes with the same stability guarantees as those of other operators that are being installed.

[msfrucht]

Tried that. Existing check in install.sh for current install blocks use of install.sh as an upgrade method.

if kubectl get deployment olm-operator -n ${namespace} > /dev/null 2>&1; then
    echo "OLM is already installed in ${namespace} namespace. Exiting..."
    exit 1
fi

Though from what I can read, the script should work with this check removed to perform an upgrade if all that is necessary is applying the updated files.

[exdx]

Yeah that's totally valid -- I believe we added that check to prevent users from accidentally installing multiple versions of OLM on their cluster, but it doesn't allow for the case where you would intentionally want this during an upgrade.

Would adding a flag or override to the script that if set, would skip the early exit checks make sense? Then the default behavior would be the same, but if upgrading, it would then go through as well

[msfrucht]

A "-u, --upgrade" flag would certainly be in the style of other script based installer like Python pip with self-update features.

[needleshaped]

Feature request for update script also made here: #2695