Update Portworx file system dependencies in OCP GCP

The Portworx Enterprise container ships with an archive containing precompiled modules for the kernels which were available at the time the container was released. If a kernel is released after a Portworx release, a pre-compiled version of the modules will not exist in the container. If Portworx is deployed in a setup which does not have access to mirrors.portworx.com to download the latest modules (for example, an air-gapped deployment), then Portworx will fail to come up.

Alternatively, in such deployments, you can publish the updated containers to internal container repositories where Portworx can download the new kernel modules.

Regardless of whether your cluster accesses the updated container through mirrors.portworx.com or an internal container registry, you can use that container to update your nodes' Portworx installation to include the latest batch of precompiled modules. Perform the update by running a DaemonSet in the cluster where Portworx has been installed.

Update filesystem dependencies

1. Run the following command to download the correct version of the manifest that installs a DaemonSet in your cluster. Substitute <px-version> with the specific Portworx version you require:

   REL="/<px-version>" && curl -fsL -o pxlibupdate-spec.yaml "https://install.portworx.com${REL}?comp=pxlibupdate"

2. Apply the spec:

   oc apply -f pxlibupdate-spec.yaml

   Inspect the pod log to determine success or failure of the update.

3. Run the following command to restart all Portworx pods:

   oc label nodes --all px/service=restart --overwrite 

   Wait for a few minutes for the Portworx pods to restart. You will notice that Portworx is deployed with the latest kernel version.

The DaemonSet above will update the pre-compiled module archives within the Portworx install location on the node (for example, /opt/pwx).

Note that this process assumes that Portworx is already installed since it will only update an existing installation. The existing installation's version will be checked for compatibility with the update container, and if it is not compatible, then the update will not be done.