2021.1.6 (October 2021)

Revise Reference to Ingress in Initial kustomization.yaml File

Because of changes to Kubernetes, the reference to ingress in the base kustomization.yaml file for earlier versions of SAS Viya must be revised for version 2021.1.6.

Here is how the base kustomization.yaml file should appear for earlier versions:

resources:
- sas-bases/base
- sas-bases/overlays/cert-manager-issuer
- sas-bases/overlays/network/ingress

Here is the same block for version 2021.1.6:

resources:
- sas-bases/base
- sas-bases/overlays/cert-manager-issuer
- sas-bases/overlays/network/networking.k8s.io

Change in Storage Class Configuration for SAS Programming Environment

The method by which you assign the storage class for runtime storage for processes such as SAS Compute server, SAS/CONNECT server, and SAS Batch server has been modified. If you used a YAML file to assign the storage class rather than use the default emptyDir, you must make revisions to your deployment.

1. Search for the following line in the transformers block of the base kustomization.yaml file.

   - site-config/sas-programming-environment/storage/change-viya-volume-storage-class.yaml

   If that line is present, continue with these steps. Otherwise, there are no required changes and you should skip the rest of this deployment note.

2. Copy the $deploy/sas-bases/examples/sas-programming-environment/storage/change-viya-volume-storage-class.yaml file to the site-config directory, overwriting the existing file.
3. In the copied file, replace the {{ VOLUME-STORAGE-CLASS }} variable with the volume definition of the storage location you want to use.
4. In the base kustomization.yaml file, remove the - site-config/sas-programming-environment/storage/change-viya-volume-storage-class.yaml from the transformers block.
5. Also in the base kustomization.yaml file, add the following content to the patches block:

   patches:
   - path: site-config/change-viya-volume-storage-class.yaml
     target:
       kind: PodTemplate 
       labelSelector: "sas.com/template-intent=sas-launcher"

Update CAS Servers

Version 2021.1.6 contains an update to CAS. However, until the existing CAS servers are restarted, your deployment will continue to run the earlier version.

Although you must delete the CAS server pods in order to restart CAS and complete your update, note the following caveats:

• Deleting the CAS server pods stops the running CAS servers, drops all the in-memory data, and restarts the new pods.
• The updated CAS servers might need to be reloaded with data.
• Stopping and starting the CAS servers cause an outage that will be noticeable for the end users. Make plans accordingly.

After you have performed the commands to deploy the updates, you must delete the existing CAS pods, which will restart an updated CAS server. As an administrator with namespace privileges, run the following command:

kubectl -n name-of-namespace delete pods -l app.kubernetes.io/managed-by=sas-cas-operator

Check Open Distro for Elasticsearch Cluster

Due to a timing issue, an update can result in an invalid StatefulSet manifest, which prevents the sas-opendistro-default-0 (or other master/data nodes) from coming up.

1. After updating SAS Viya, ensure that the Open Distro for Elasticsearch cluster pods are running. If your deployment uses the default topology for Open Distro for Elasticsearch, use the following command:
   kubectl -n name-of-namespace get pods | grep sas-opendistro-default

   kubectl -n name-of-namespace get pods | grep sas-opendistro-default

   If you created a custom topology using the custom-topology.yaml example file, use the following command:

   kubectl -n name-of-namespace get pods | grep sas-opendistro-node-set

   kubectl -n name-of-namespace get pods | grep sas-opendistro-node-set

   In this command, node-set is a custom Elasticsearch node set defined in the example file. If you have more than one custom node set, the command should be performed for each node set.

2. Restart each pod that is in a CrashLoopBackOff state in the output from step 1. To restart an Elasticsearch pod in a default topology, delete it:
   kubectl -n name-of-namespace delete pod sas-opendistro-default-pod-number

   kubectl -n name-of-namespace delete pod sas-opendistro-default-pod-number

   To restart an Elasticsearch pod in a custom topology:

   kubectl -n name-of-namespace delete pod sas-opendistro-node-set-pod-number

   kubectl -n name-of-namespace delete pod sas-opendistro-node-set-pod-number

3. Review the log of each sas-opendistro-default-pod-number pod (or each sas-opendistro-node-set-pod-number pod if you have custom topologies) for the following error.

   org.elasticsearch.bootstrap.StartupException: java.lang.IllegalArgumentException: unknown setting [node.roles] please check that any required plugins are installed, or check the breaking changes documentation for removed settings

   If the error is in the log, restart the pod using the commands described in step 2.

Delete espserver before the Update

When you update to version 2021.1.6, the ESPServer custom resource must be deleted in order to pick up changes during the update.

Before you update to 2021.1.6, delete the existing ESPServer custom resource using the following command:

kubectl -n name-of-namespace delete espserver --all

To verify that the custom resource was deleted:

kubectl -n name-of-namespace get espserver

The following output indicates a successful deletion:

No resources found in name-of-namespace namespace.