How to customize your Programming Run-Time Servers pod names

As a SAS Viya administrator you may want to identify different workloads based on the different launcher contexts that you have defined. Currently, by default, all Programming Run-Time Servers pods will have the same, based on the type, prefix for pod names and there is no way to differentiate them from looking at the pod names.

For instance if you use a compute server either by using SAS® Data and AI Studio, SAS Enterprise Guide or the SAS extension for Visual Studio Code the pods are all named using the same prefix. What if you wanted to name them differently, so you could easily distinguish them. The same holds true for batch and connect servers. This article will show you how you can change the prefix being used.

What we will cover

Default names assigned to Programming Run-Time Servers
Where can I change the name of my Programming Run-Time Servers

Default names assigned to Programming Run-Time Servers

The Programming Run-Time Servers use the same prefix for the pod name based on the type. The default name for a compute server pod is sas-compute-server-<some-id>-<hash>. Similar a batch server is named sas-batch-server-<some-id>-<hash> and for a SAS/CONNECT Server it is sas-connect-server-<some-id>-<hash>. When you use the background submit in SAS Data and AI Studio the pod name is <program-name>sas-<some-id>-<hash>.

You can get a list of all pods started by the launcher service using the kubectl command. See the example below.

kubectl -n edu get pods -l 'sas.com/created-by=sas-launcher'  -L launcher.sas.com/username,launcher.sas.com/job-type,launcher.sas.com/requested-by-client --sort-by=.metadata.creationTimestamp

The -l option is the selector for the pods it is based on a label=value. The -L option determines which labels should be shown in the output in addition to the standard fields.

The output can look like this:

From the -L option we do have three additional columns that give us more details. There are more labels available.

Column	Description
USERNAME	The user that is running this SAS Runtime Server
JOB TYPE	Indicates the type of server
REQUESTED BY CLIENT	Indicates which application initiated this server sas.studio: the SAS Data and AI Studio application vscode: SAS Extension to Visual Studio Code seguide: SAS Enterprise Guide sas.compute: Might indicate it is a reusable compute server, for instance used by jobs. But it can also be a background submit from SAS Data and AI Studio. sas.cli: a batch server created by the sas-viya batch jobs submit-pgm command This is not a complete list.

Now you might want to be able to better distinguish the different compute servers by using a different name prefix than sas-compute-server-. Same applies to batch- and connect servers as well. You might have created different launcher contexts to specify resource limits and want this to be visible in the pod name, so you can see directly from the pod name that a different launcher context was used.

Where can I change the name of my Programming Run-Time Servers

The image below explains the relationship between the different context definitions. It is from the article Announcing Project Mountpoint – Guidance to configure storage for SAS Viya.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

In this article we only talk about the SAS Viya Platform Resources, so the SAS Batch/Compute/Connect Context and the SAS Launcher Context.

Using SAS Environment Manager

Using SAS Environment Manager and the Contexts page we have the ability to work with launcher contexts as well as compute-, batch- and connect contexts. We first look at a launcher context. In the Advanced tab you will see the "Job name prefix:" field. This is the setting, where you can enter the prefix you want to use for this specific launcher context. Please note, a launcher context might be used by several compute (batch, connect) contexts.

The launcher context being used by a compute server is named in the compute context definition. The example below is from a reusable compute server.

Running the kubectlcommand to list the SAS Runtime Server pods will now show this:

We can see that the prefix defined in the launcher context is now used by the reusable compute server. We have several of them because there were many requests to run a job at the same time.

Using the sas-viya command line interface

Context definitions can also be created or updated using the sas-viya command line interface. The SAS Extension for Visual Studio Code uses by default the SAS Job Execution compute context. Lets look how we can change the prefix for pod names used by this compute context using the sas-viya CLI.

First we need to get the launcher id used by the compute context.

launchContextId=$(sas-viya --output fulljson compute contexts show --name "SAS Job Execution compute context" | jq -r '.launchContext.contextId')

Next we can update the corresponding launcher context

sas-viya launcher contexts update --context-id $launchContextId --job-name-prefix sas-cs-jobexec- --force

Next time a new compute server is created by the SAS Extension for Visual Studio Code the pod name starts with the defined prefix.

Keep in mind, that the user can change the compute context name used in the connection profile in the SAS extension. Likewise a SAS Enterprise Guide user can specify which compute context to use.

NOTE: Actually any compute server using the SAS Job Execution compute context will now use the new prefix.

By default all users have access to all context definitions. See Create group-specific and user-specific compute contexts – Part 1 – manual method and Create group-specific and user-specific compute contexts – Part 2 – scripted method for ways to secure the different context definitions.

Get the pod name in a SAS program

In a SAS program you can get the pod name using the macro variables SYSHOSTNAME or SYSTCPIPHOSTNAME. However sometimes the pod name is longer than 63 characters, so the name would be truncated. You can make use of the %SYSGET(SAS_K8S_POD_NAME) macro function to get the full pod name.

Summary

We have seen examples on how we can set the job name prefix using SAS Environment Manager or the sas-viya command line interface. For complete control you might want to have for each compute/batch/connect context a corresponding launcher context. This will ensure that you can identify each pod by its prefix and know which launcher context was involved. This can be helpful for launcher contexts that have settings for specific CPU and memory resources being available.