Updating script-installed deployments

You can reconfigure and update the software that is already installed. You can modify the installed software, remove it, and add new components. An update to the custom resource (CR) overwrites the deployed resources. The operator applies the changes during the control loop (observe, analyze, act) that occurs as a result of constantly watching the state of the Kubernetes resources.

Before you begin

If you plan to remove capabilities, make sure that you back up the databases, the files that are stored on the persistent volumes, and any other data that you want to keep.

About this task

The following progress bar shows you where you are in the installation process. You can click the completed parts in the diagram to go back and check that you did everything that you needed to do.

Progress bar = Install Planning for a production deployment Preparing for a production deployment Creating a production deployment Completing post-deployment tasks

You must use the same CR YAML file that you deployed with the operator to make the updates. For example, scripts/generated-cr/ibm_cp4a_cr_final.yaml.

Note: If you selected "FileNet Content Manager" with no other capabilities, then the script names the custom resource file ibm_content_cr_final.yaml. The custom resource in this case sets the Kind parameter to Content instead of ICP4ACluster.
Restriction: If you want or need to update values in a production deployment that you made in the Form View, you must edit the deployment in the YAML View. You can edit true or false values in the Form View, but the other parameters need to be done in the YAML View. You can access the custom resource from the YAML tab, or by clicking Actions > Edit ICP4ACluster. YAML view

You can make your update to the custom resource file by running the deployment script if you used the script to generate it. You select an existing installation in the script user interface and the file that you used is located by the script. You do need to apply the modified CR after you enter your changes in the user interface.

You can also edit the file manually. The following steps go through the manual procedure, but you can replace steps 2 and 3 by running the deployment script to make the update. For more information, see Option 2a: Generating the custom resource with the deployment script.

Restriction: The deployment script does not apply customizations that you added to your deployment in an update. If you added a customization to any component that does not exist in the simplified pattern templates, then these configurations are not applied by the script. To keep your customizations, make the updates manually or apply them again after you make your updates by running the deployment script.

Procedure

  1. Review your CR YAML file to make sure it contains all of your intended modifications.
    cat /scripts/generated-cr/ibm_cp4a_cr_final.yaml
  2. Refer to the information in Option 1: Preparing your cluster for an online deployment and Checking and completing your custom resource to pick and choose the configuration parameters to update.
  3. When you are done with all of the updates that you want to make, run the apply command to update the operator.

    Using the OpenShift CLI.

    oc apply -f <ibm_cp4a_my_cr_final.yaml> --overwrite=true

    The operator reconciliation loop can take around an hour or even longer depending on the capabilities that you included in your custom resource.

    Monitor the status of your pods by using the OpenShift CLI:

    oc get pods -w
    Note: You can also use oc edit ICP4ACluster <MY-INSTANCE> to open the default UNIX visual editor (vi) in the pod.
  4. When all of the pods are "Running", you can access the status of your services with the status command.

    Using the OpenShift CLI.

    oc status

Results

Note: In some cases, changes that you make in the custom resource YAML by using the operator or directly in the environment are not automatically propagated to all pods. For example, modifications to data source information or changes to Kubernetes secrets are not seen by running pods until the pods are restarted.

If changes applied by the operator or other modifications that are made in the environment do not provide the expected result, restart the pods by scaling the impacted deployments down to 0. Scale the pods back up to have Kubernetes (OpenShift) terminate the existing pods and create new ones.

If you changed the IBM Navigator plug-ins, you must restart the pod for the changes to show up.