SAS Support Communities

 SAS Administrators use autoexec code blocks in both the compute service configuration which applies to all compute sessions, and in compute contexts which apply only to compute sessions started under that context, to pre-configure their users' SAS Programming Run Time sessions in various ways. Autoexec code can be used to define commonly-used library references, macros, SAS system options, lockdown paths and more.   My last post here presented a script to add statements such as lockdown paths and librefs to SAS compute service autoexec. This post presents a similar script, which does the same for an existing compute context.   Modifying an existing compute context is very easy to do interactively using SAS Environment Manager. And it's also easy to create entirely new compute contexts with properties set as you wish using the SAS Viya CLI. But sometimes, SAS Administrators would prefer to script and automate this kind of configuration, including changes to existing compute contexts in a SAS Viya deployment.   Updating an existing compute context from the command line has just become easier with a new pyviyatool, updatecomputecontext.py.   Like the script presented in the last post, the script presented in this one tries to be idempotent: it checks whether the lines of SAS code to be added are already in the specified compute context's autoexec code block. If they are not it adds them and updates the compute context with the resulting JSON file (using the new updatecomputecontext.py pyviyatool). The way autoexec code is stored in the JSON representation of a compute context is slightly different from the way it is stored in the JSON representation of the compute service autoexec_code configuration instance, and this script accounts for that slight difference.   Creating an entirely new compute context, complete with autoexec lines if desired, is fairly easy in a script. You can create a JSON file named e.g. /tmp/compute_context.json containing the desired compute context definition in any of several ways (from a template, download the JSON for an existing context etc.). Then you can pass that JSON file into a command like this:   sas-viya compute contexts create -r -d @/tmp/compute_context.json   What we didn't have until now was a neat method to modify an existing compute context from the command line. There was no such command as sas-viya compute contexts update in the compute plugin to the SAS Viya CLI at the time of writing. So we cannot update the compute context with a command like this: sas-viya compute contexts update -r -d @/tmp/compute_context_config_with_autoexec_updated.json   As of SAS Viya 2024.10, sas-viya compute contexts has sub-commands for create, delete, generate-template, list, show and validate. But there is no update sub-command, which is why I wrote the new pyviyatool.   The closest thing you could do previously, using just the SAS Viya CLI and without writing code that calls REST APIs, was to delete an existing compute context and then create a new one of the same name from a JSON file. That can work, but results in the compute context resource ID changing, which can create its own issues with other automation that relies on the context ID. Modifying an existing context is preferable.   Update a compute context autoexec from a bash script   Define add_code_to_compute_context_autoexec()   Below is a custom bash function called add_code_to_compute_context_autoexec() which adds one or more lines of SAS code to the existing autoexec code block in an existing compute context, if the new code lines are not already part of the existing compute service autoexec. It uses the SAS Viya Command-Line Interface, the JSON query utility jq and the new pyviyatool, updatecomputecontext.py.   add_code_to_compute_context_autoexec () { # Delete any old working files from previous runs: /tmp/compute_*.json, /tmp/compute_*.txt rm -f /tmp/compute_*.json /tmp/compute_*.txt compute_context_name=${1} file_code_to_add=${2} # Test that the first input parameter is the name of a SAS compute context, and returns valid JSON document sas-viya --output fulljson compute contexts show -n "${compute_context_name}" 2>&1 > /tmp/compute_context_config.json # cat /tmp/compute_context_config.json if [ -s /tmp/compute_context_config.json ]; then # Something was written to the file - is it JSON? retval=$(jq -re '""' /tmp/compute_context_config.json 2>&1) # echo "Found compute context named ${compute_context_name} in SAS Viya" if [ ! -z "${retval}" ]; then echo "Error: invalid JSON while getting \"${compute_context_name}\" using sas-viya CLI - ${retval}." return 1 fi else echo "Error: Compute context \"${compute_context_name}\" not found." return 1 fi # Test that the second input parameter is populated and the file path contains exists if [ -f ${file_code_to_add} ]; then # echo "File \"${file_code_to_add}\" exists" # Delete some of the parts of compute_context_config.json we won't need. # (It may still contains some parts we don't need, but this is clean enough to be readable.) jq -r 'del( .links )' /tmp/compute_context_config.json > /tmp/compute_context_config_clean.json # cat /tmp/compute_context_config_clean.json # Many compute contexts, and all out-of-the-box compute contexts do not have any autoexec code # Therefore, they do not have the keys for one in their JSON definition. # Check whether the key for an autoexec code block exists. If it does, get the autoexec code from it. # If it does not, create it. if [[ $(jq -e '.environment | has("autoExecLines")' /tmp/compute_context_config_clean.json) == "true" ]]; then echo 'Compute context has autoExecLines' jq -r '.environment.autoExecLines[]' /tmp/compute_context_config_clean.json > /tmp/compute_context_autoexec.txt cp /tmp/compute_context_config_clean.json /tmp/compute_context_config_with_autoexec.json else echo 'Compute context does not have autoExecLines, adding an empty array for them' jq -r '.environment |= {"autoExecLines": []} + . ' /tmp/compute_context_config_clean.json > /tmp/compute_context_config_with_autoexec.json # cat /tmp/compute_context_config_with_autoexec.json rm -f /tmp/compute_context_autoexec.txt touch /tmp/compute_context_autoexec.txt fi # cat /tmp/compute_context_config_with_autoexec.json # cat /tmp/compute_context_autoexec.txt # Convert the multiline content of ${file_code_to_add} to a single line # with a \n for each newline, for use in the test below to see if it is already in the existing autoexec. cat ${file_code_to_add} | sed -n 'H;${x;s/^\n//;s/\n/\\n/g;p}' > /tmp/compute_autoexec_code_to_add_oneline.txt # cat /tmp/compute_autoexec_code_to_add_oneline.txt # Convert the multiline content of /tmp/compute_context_autoexec.txt to a single line # with a \n for each newline, for use in the test below. cat /tmp/compute_context_autoexec.txt | sed -n 'H;${x;s/^\n//;s/\n/\\n/g;p}' > /tmp/compute_context_autoexec_oneline.txt # cat /tmp/compute_context_autoexec_oneline.txt # Load strings containing the context's existing autoexec code and the candidate code to add to it in variables. compute_context_autoexec_code_oneline=$(cat /tmp/compute_context_autoexec_oneline.txt) compute_context_autoexec_code_to_add_oneline=$(cat /tmp/compute_autoexec_code_to_add_oneline.txt) # echo ${compute_context_autoexec_code_oneline} # echo ${compute_context_autoexec_code_to_add_oneline} # If compute_autoexec_code_oneline.txt does not already contain compute_autoexec_code_to_add_oneline.txt, add it. If it already contains that block of code verbatim, do nothing. if [[ ${compute_context_autoexec_code_oneline} == *"${compute_context_autoexec_code_to_add_oneline}"* ]]; then echo "The context's autoexec code block already contains that code. Nothing to do." else echo "The context's autoexec code block does not yet contain that code. Adding it." # Append the new autoexec code to the existing autoexec code block rm -f /tmp/compute_context_autoexec_code_multiline_final.txt cat /tmp/compute_context_autoexec.txt \ ${file_code_to_add} > /tmp/compute_context_autoexec_code_multiline_final.txt # cat /tmp/compute_context_autoexec_code_multiline_final.txt # Convert it back to a JSON array jq -R -s 'split("\n")' < /tmp/compute_context_autoexec_code_multiline_final.txt > /tmp/compute_context_autoexec_array.txt # cat /tmp/compute_context_autoexec_array.txt # Replace the existing autoexec lines array in the JSON for the compute context with this new one autoexec_array=$(cat /tmp/compute_context_autoexec_array.txt) # echo $autoexec_array jq -r --argjson autoexec_array "$autoexec_array" '.environment.autoExecLines = $autoexec_array' /tmp/compute_context_config_with_autoexec.json > /tmp/compute_context_config_with_autoexec_updated.json # cat /tmp/compute_context_config_with_autoexec_updated.json # There is no such command as "sas-viya compute contexts update" in the compute plugin to the SAS Viya CLI at the time of writing. # So we cannot update the compute context with a command like this: # # sas-viya compute contexts update -r -d @/tmp/compute_context_config_with_autoexec_updated.json # # "sas-viya compute contexts" has sub-commands for create, delete, generate-template, list, show and validate. # But at the time I wrote this example, there is no "update" sub-command, so I wrote a pyviyatool to update compute contexts. # Update the compute context using the updatecomputecontext.py pyviyatool ${pyviyatools_path}/updatecomputecontext.py -n "${compute_context_name}" -f /tmp/compute_context_config_with_autoexec_updated.json fi else echo "File \"${file_code_to_add}\" not found" fi }   Some notes:   add_code_to_compute_context_autoexec()relies on the SAS Viya Command-line Interface (sas-viya), and expects to find it from the command sas-viya. So, before you use the function in this post, you must install and configure the CLI to connect to your SAS Viya deployment, and then authenticate as a user who is a SAS Administrator. This has been written about a lot, not least in these posts: Gerry Nelson: SAS Viya Command-Line Interface for Administration (update) Gerry Nelson: Overview of installing and using the SAS Viya containerized CLI Stuart Rogers: SAS Viya CLI with Group-Managed Service Accounts If the sas-viya executable or an alias or link to it is not in your path, you may need to modify the function to add the path to sas-viya in your environment, or provide it in an environment variable. The function uses jq: https://github.com/jqlang/jq. The function uses a new pyviyatool,updatecomputecontext.py. If you have not installed the pyviyatools, see the project README.md or INSTALL.md instructions in GitHub. If you already have the pyviyatools installed from before 18 November 2024, you may need to run a git pull or similar command to get updatecomputecontext.py. The function deletes and creates a set of text files (containing JSON and plain text) in the /tmp directory, named like /tmp/compute_*.json and  /tmp/compute_*.txt. If this might cause an issue in your environment, feel free to modify the function as you see fit to store the temporary files somewhere else. There are quite a few commented-out cat and echo statements, which were useful to me during the function's development. I left them in the script in case they prove useful to you.   The function expects two (positional) parameters. The first is the name of the compute context to be updated. The second is the path to a file containing one or more lines of new SAS code, to be added to that compute context's autoexec code lines.   Call add_code_to_compute_context_autoexec()   To call the function (after authenticating against the SAS Viya CLI and doing the other things in the bullet points just following the script above), simply create a text file containing the SAS code statements you wish to add (if they are not already in the chosen compute context's autoexec code block), and call the function passing context name, and the path to that text file as parameters:   # Name of compute context to update compute_context_name="SAS Studio compute context" # Then, create a file containing the SAS code you want to add to an autoexec if it doesn't # already contain this code. tee /tmp/autoexec_code_to_add.txt > /dev/null << EOF lockdown path='/shared_path'; libname shrdata '/shared_path/data'; EOF # cat /tmp/autoexec_code_to_add.txt add_code_to_compute_context_autoexec "${compute_context_name}" "/tmp/autoexec_code_to_add.txt"   Depending on whether the compute context already has SAS code lines in its autoexec or not, the first line of expected output may either be:   Compute context has autoExecLines   or:   Compute context does not have autoExecLines, adding an empty array for them   Then the rest of the expected output will look something like this:   The context's autoexec code block does not yet contain that code. Adding it. Compute context: 'SAS Studio compute context' found in SAS Viya deployment with id: 9f0c2e7e-0cd3-4d01-bcd8-8230611119d2 Found 'SAS Studio compute context' in input file '/tmp/compute_context_config_with_autoexec_updated.json' The compute context id '9f0c2e7e-0cd3-4d01-bcd8-8230611119d2' in the input file matches the one in the SAS Viya deployment. Context updated.   If you were to run the function a second time, with the same content in the file you pass as a parameter, you should instead see this:   Compute context has autoExecLines The context's autoexec code block already contains that code. Nothing to do.   The example autoexec code statements shown above are:   lockdown path='/shared_path"; libname shrdata '/shared_path/data';   These statements would make sense for a SAS Viya deployment in which you have mounted a volume into your compute server (and other SAS Programming Runtime) pods, which makes the filesystem path /shared_path available to processes running in those pods. I discussed this in my previous post and won't duplicate that discussion here.   You could add any valid and relevant SAS code statements to your equivalent of my example /tmp/autoexec_code_to_add.txt. Anything that makes sense in an autoexec code block should work.   As with the script in my previous post, be consistent with your indentation, trailing spaces and whitespace in general, if you care about the idempotency part of the function: that it won't add code that already exists in the compute context autoexec. The function doesn't do anything particularly clever about trimming white space, so for example if your compute service autoexec contains a line indented by one space, and you run the function to add the same line not indented, you should expect the 'duplicate' line to be added to the autoexec, and possibly some warnings in the server logs when compute sessions start up.   Update a compute context autoexec interactively, in SAS Environment Manager   If you only need to add code to a compute context autoexec once, and you don't need to automate this task, do it interactively in SAS Environment Manager. This is documented in SAS Help Center, in the SAS Environment Manager User's Guide, in the Contexts Page section under Create a Compute Context and Edit a Context.   Sign in as an administrator and navigate to the Contexts page. (Users who are not members of the SAS Administrators custom group don't see the Contexts page). Choose Compute Contexts from the View dropdown, then select a compute context, e.g. SAS Studio Compute Context. Click the Edit button on the right-hand side of the application page, to edit the context.   SAS Environment Manager's Contexts page, showing compute contexts and the edit button.   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 the Edit Compute Context dialog, switch to the Advanced tab. The field labelled "Enter each autoexec statement on a new line:" contains the autoexec code statements that are run as compute sessions under this compute context start:   SAS Environment Manager, Context page, editing a compute context. The Advanced tab of the Edit Compute Context dialog has a field containing lines of autoexec code for this context.   Adding your desired lines of SAS code to be automatically executed when compute sessions under this context start is all you need to do if you don't need to script anything. But for those of us who look after automatically-deployed and automatically-updated  environments, the add_code_to_compute_context_autoexec() bash function does something we could not have done easily before.   See you next time!     Find more articles from SAS Global Enablement and Learning here. ... View more

How would you add a few lines of code to your compute service autoexec from your post deployment automation scripts, if they aren't in the autoexec already?   Adding SAS code to a compute service or compute context autoexec is very easy to do interactively using SAS Environment Manager. If you only need to add a bit of SAS code to an autoexec code block once, then using Environment manager is definitely the quickest and easiest way to do it.   However, there are situations such as automating post deployment configuration for SAS Viya environments you design for someone else to deploy on demand, or which you will deploy over and over again, where only a scripted method will do.   In this post I'll present a custom bash function called add_code_to_compute_service_autoexec() which adds one or more lines of SAS code to the existing autoexec code block in your compute service, if the new code lines are not already part of the existing compute service autoexec.   add_code_to_compute_service_autoexec() uses the SAS Viya Command-Line Interface, and of course the wonderful JSON query utility jq. (jq is currently one of my favourite toys).     Update the Compute Service autoexec from a bash script   Define add_code_to_compute_service_autoexec()   The add_code_to_compute_service_autoexec() bash function below is idempotent: it checks whether the 'new' code is in fact already in the autoexec code block, verbatim, and it will only append the 'new' code if it is not already part of the existing code. This isn't necessarily a big 'wow' feature; your automation probably only runs once. But it's good practice.   You could use this function in your post deployment SAS Viya administration scripts to add paths to the SAS programming runtime lockdown paths list - a question from a colleague similar to the first sentence of this post prompted me to write the function and the post.   But you could also use the function to add any other one or more lines of SAS code to the autoexec. You could use it to add code to define a SAS macro that is commonly used in your organization, or to add a few libname statements or some SAS options statements that your users need immediately after deployment, and you want to ensure are in the autoexec just once, not repeated. You can even do all of those in one call.   Here is the bash script file defining the function add_code_to_compute_service_autoexec():   #!/bin/bash ############################################################################### # Define function to add content of a text file to global compute service autoexec # Usage: add_code_to_compute_service_autoexec ${file_containing_compute_autoexec_code_to_add} ############################################################################### add_code_to_compute_service_autoexec () { # Delete any old working files from previous runs: /tmp/compute_*.json, /tmp/compute_*.txt rm -f /tmp/compute_*.json /tmp/compute_*.txt # Test that the input parameter is populated and the file path contains exists file_code_to_add=${1} if [ -f ${file_code_to_add} ]; then echo "File \"${file_code_to_add}\" exists" # Get a JSON file representing the whole of the current (global) compute service configuration instance, with all its sub-instances. This is a fairly large JSON document. sas-viya --output fulljson configuration configurations download -d sas.compute.server -s compute > /tmp/compute_config.json # cat /tmp/compute_config.json # Delete some of the parts of compute_config.json we won't need, # including config instances other than the autoexec one. # (It may still contains some parts we don't need, but this is clean enough to be readable.) jq -r 'del(.items[] | select(.name != "autoexec_code"))' /tmp/compute_config.json | jq -r 'del(.accept, .count, .start, .limit, .links, .items[].links)' > /tmp/compute_autoexec_config.json # cat /tmp/compute_autoexec_config.json # Extract the current contents of the autoexec block from compute_autoexec_config.json # and save it to a file. This file contains a \n for each newline. jq -r '.items[0].contents' /tmp/compute_autoexec_config.json > /tmp/compute_autoexec_code_multiline.txt # cat /tmp/compute_autoexec_code_multiline.txt # Convert the multiline content of ${file_code_to_add} to a single line # with a \n for each newline, for use in the test below to see if it is already in the existing autoexec. cat ${file_code_to_add} | sed -n 'H;${x;s/^\n//;s/\n/\\n/g;p}' > /tmp/compute_autoexec_code_to_add_oneline.txt # cat /tmp/compute_autoexec_code_to_add_oneline.txt # Convert the multiline content of /tmp/compute_autoexec_code_multiline.txt to a single line # with a \n for each newline, for use in the test below. cat /tmp/compute_autoexec_code_multiline.txt | sed -n 'H;${x;s/^\n//;s/\n/\\n/g;p}' > /tmp/compute_autoexec_code_oneline.txt # cat /tmp/compute_autoexec_code_oneline.txt # Load strings containing the existing autoexec code and the candidate code to add to it in variables. compute_autoexec_code_oneline=$(cat /tmp/compute_autoexec_code_oneline.txt) compute_autoexec_code_to_add_oneline=$(cat /tmp/compute_autoexec_code_to_add_oneline.txt) # echo ${compute_autoexec_code_oneline} # echo ${compute_autoexec_code_to_add_oneline} # If compute_autoexec_code_oneline.txt does not already contain compute_autoexec_code_to_add_oneline.txt, add it. If it already contains that block of code verbatim, do nothing. if [[ ${compute_autoexec_code_oneline} == *"${compute_autoexec_code_to_add_oneline}"* ]]; then echo "The autoexec code block already contains that code. Nothing to do." else echo "The autoexec code block does not yet contain that code. Adding it." rm -f /tmp/compute_autoexec_code_multiline_final.txt cat /tmp/compute_autoexec_code_multiline.txt \ ${file_code_to_add} > /tmp/compute_autoexec_code_multiline_final.txt # cat /tmp/compute_autoexec_code_multiline_final.txt # Replace the content value in compute_autoexec.json and save the resulting JSON in compute_autoexec_updated.json compute_autoexec_content=$(cat /tmp/compute_autoexec_code_multiline_final.txt) # echo $compute_autoexec_content jq -r --arg compute_autoexec_content "${compute_autoexec_content}" '.items[0].contents = $compute_autoexec_content' /tmp/compute_autoexec_config.json > /tmp/compute_autoexec_config_updated.json # cat /tmp/compute_autoexec_config_updated.json # Update the compute service configuration with this new autoexec section, leaving # the rest unchanged sas-viya configuration configurations update --file /tmp/compute_autoexec_config_updated.json fi else echo "File \"${file_code_to_add}\" not found" fi }   Some notes:   add_code_to_compute_service_autoexec()relies on the SAS Viya Command-line Interface (sas-viya), and expects to find it from the command sas-viya. So, before you use the function in this post, you must install and configure the CLI to connect to your SAS Viya deployment, and then authenticate as a user who is a SAS Administrator. This has been written about a lot, not least in these posts: Gerry Nelson: SAS Viya Command-Line Interface for Administration (update) Gerry Nelson: Overview of installing and using the SAS Viya containerized CLI Stuart Rogers:  SAS Viya CLI with Group-Managed Service Accounts If the sas-viya executable or an alias or link to it is not in your path, you may need to modify the function to add the path to sas-viya in your environment, or provide it in an environment variable. This function also relies on jq: https://github.com/jqlang/jq. It deletes and creates and  a set of text files (containing JSON and plain text) in the /tmp directory, named like /tmp/compute_*.jsonand  /tmp/compute_*.txt. If this might cause an issue in your environment, feel free to modify the function as you see fit to store the temporary files somewhere else. There are quite a few commented-out cat and echo statements, which were useful to me during the function's development. I left them in the script in case they prove useful to you.   The function expects one (positional) parameter, which is the path to a file containing one or more lines of new SAS code, to be added to the global compute service autoexec.   Call add_code_to_compute_service_autoexec()   To call the function (after authenticating against the SAS Viya CLI and doing the other things in the bullet points just following the script above), simply create a text file containing the SAS code statements you wish to add (if they are not already in the compute service autoexec code block), and call the function passing the path to that text file as its only parameter:   #!/bin/bash # Create a file containing the SAS code you want to add to an autoexec if it doesn't # already contain this code. tee /tmp/autoexec_code_to_add.txt > /dev/null << EOF lockdown path='/shared_path'; libname shrdata '/shared_path/data'; EOF # cat /tmp/autoexec_code_to_add.txt add_code_to_compute_service_autoexec "/tmp/autoexec_code_to_add.txt"   Expected output:   File "/tmp/autoexec_code_to_add.txt" exists The autoexec code block does not yet contain that code. Adding it. "PATCH" "/configuration/configurations" complete from "/tmp/compute_autoexec_config_updated.json".   If you were to run the function a second time, with the same content in the file you pass as a parameter, you should instead see this:   File "/tmp/autoexec_code_to_add.txt" exists The autoexec code block already contains that code. Nothing to do.   The example autoexec code statements shown above would make sense for a SAS Viya deployment in which you have mounted a volume into your compute server (and other SAS Programming Runtime) pods, which makes the filesystem path /shared_path available to processes running in those pods.   Gerry Nelson touched on how to do this in the section titled Mount NFS directories into Compute Pods, in his post SAS Viya: making user home-directories available to compute. It's quite a common deployment or post-deployment configuration task, and is described in the SAS Viya Platform Operations documentation, under Using Kubernetes Volumes for User Home Directories and Using NFS Server to Mount Home Directory. Those brief entries refer you to a README file in your deployment assets, here: $deploy/sas-bases/examples/sas-launcher/configure/README.md (for Markdown format) or here: $deploy/sas-bases/docs/configuration_settings_for_sas_launcher_service.htm (for HTML format).   If you are an expert in LOCKDOWN, you might know that the lockdown path statement in the example autoexec code above is not needed for the libname statement which follows, because libname statements in the global compute server autoexec and in compute context autoexec are run before the compute session enters the locked down state. However, adding the path /shared_path to the lockdown paths list would enable users to later run their own libname statements, like this for example:   libname projectx '/shared_path/projectx';   That libname statement would not be allowed in user code if /shared_path is not in the lockdown paths list. See the LOCKDOWN documentation in SAS Help Center, and this post for more on LOCKDOWN:   David Stern: How SAS Watchdog restricts filesystem access for Open Source programs   You could also add other code to your equivalent of my example /tmp/autoexec_code_to_add.txt. Anything that makes sense in an autoexec code block should work.   Be consistent with your indentation, trailing spaces and whitespace in general, if you care about the idempotency part of the function: that it won't add code that already exists in the compute service autoexec. The function doesn't do anything particularly clever about trimming white space, so for example if your compute service autoexec contains a line indented by one space, and you run the function to add the same line not indented, you should expect the 'duplicate' line to be added to the autoexec, and some warnings in the server logs when compute sessions start up.   What about automating updates for compute context autoexec code?   I also worked on a similar function to add lines to a compute context autoexec code block, as well as the one for the global compute service autoexec code block.   That proved more difficult, partly because the way autoexec lines are stored in the JSON representation of a compute context (a dictionary of strings, one string per autoexec line) is slightly different to how they are stored in the JSON for the compute service (a single string value with embedded newlines encoded as \n) which needs to be handled as appropriate for the idempotency test.   But it was more difficult mostly because there is not currently a SAS Viya Command-line Interface command like sas-viya compute contexts update. There is a command to create a new compute context from a JSON file, but not one to update an existing one. I reworked my idempotency check with the different representation of lines, but the second issue just made it a bit too much of a stretch for this post.   I think it can be done with an as-yet-to-be-written pyviyatool, similar to setcomputecontextattributes.py. But that one is towards the more complicated end of the scale among our pyviyatools and and I wanted to publish what I have so far, so that will have to wait for another time. Let me know in the replies if you'd like it sooner rather than later!   Update the Compute Service autoexec interactively, in SAS Environment Manager   If you only need to add code to your compute service autoexec once for a SAS Viya deployment, and you don't need to automate this task, do it interactively in SAS Environment Manager. This is documented in SAS Help Center, in the SAS Viya Platform Administration guide, Servers and Services, Programming Run-time Servers, SAS Compute: Server, Service and Contexts, in the How To section Edit Configuration Instances.   Sign in as an administrator and navigate to the Configuration page. (Users who are not members of the SAS Administrators custom group don't see the Configuration page). I find the easiest way to get to the configuration instance is to choose Definitions from the View dropdown, then type 'compute' in the search box, and select 'sas.compute.server', but there are other ways to get to the same set of configuration instances. Collapse the set of configuration instances on the right-hand side of the application page, so you can see them all.   Compute Service configuration instances, highlighting the autoexec code instance   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Edit the configuration instance for Compute Service: autoexec_code. In the Edit sas.compute.server Configuration dialog, the contents field contains the autoexec code statements that are run as every compute session starts, regardless of which compute context it is running in:   Edit the global compute service autoexec code here   That is all you need to do if you don't need to script anything. But for those of us who look after automatically-deployed environments, I think the add_code_to_compute_service_autoexec() function, or something similar, will fill a gap in our toolset.   See you next time!     Find more articles from SAS Global Enablement and Learning here. ... View more

I was recently asked how to get the return code of a SAS batch job from the command line, to find out if it has succeeded or failed. The context was for something in a customer's existing workflow engine (a.k.a. a job flow scheduler), which in their case was not Argo Workflow or Apache Airflow, but rather something script-based. They wanted their flow scheduler to run the SAS batch job, and after that do one thing if the batch job succeeded, and depending on the particular job either do something else or stop the flow if the batch job failed.   For customers using Apache Airflow or Argo Workflow as their scheduler, this may be supported by existing, well described modules or methods of integrating them with SAS batch. There are links to Gerry Nelson's posts covering that in the references bit at the end. But for setting up SAS batch jobs in any other scheduler that uses a script-based wrapper for each step, what follows might save you some time.   In this post we'll walk through a set of short bash examples that submit SAS batch jobs, query their status and other properties and parse the JSON output produced by those queries to get the values you want. We also save the return code and download the results fileset containing the SAS log output, and other files.   You can use these example scripts as they are, or modify them to suit your particular needs. It is convenient and a good idea to wrap some of the repetitive parts of the examples that follow in a bash function, so we will see how to do that too.   For more on the SAS Viya CLI in general, and for how to get started using the batch plug-in, there are links to great posts and documentation about both in the references at the end. I won't duplicate their work in this post where I can avoid it. Let's get started.       Prerequisite environment set up and experience   In the examples which follow, I will assume you have already installed SAS Viya and the SAS Viya CLI., I will assume you have set up a default profile for the SAS Viya CLI, and have successfully authenticated through the CLI as a user who can submit batch jobs. If not, there are posts linked in the references section at the end of this post which will walk you through all of that, and of course the documentation covers this very well.   I also assume you know a bit about how to submit a SAS batch job from the SAS Viya CLI, and will not explain that in much detail - again, see the references section if that is new to you.   Since I will use the default profile, let's set up a bash environment variable to specify that option, and to provide a place where you could specify other options which you will always specify when you run the sas-viya batch submit-pgm command. Run this interactively in your bash shell, or add it to your own script:   # Provide a place to set some sas batch jobs command options. sas_batch_options="--context default"   The task of understanding the status and return code from a batch job is made much easier with a great little tool called jq (https://jqlang.github.io/jq/) which we always install in our administration clients, and which we use to parse JSON documents such as the output that the SAS Viya CLI can produce.       Sample SAS programs   To demonstrate we are getting the return codes from SAS batch jobs correctly, let's create three SAS programs that are variously supposed to run successfully, run with errors, and abort. They should finish with different return codes when we run them as SAS batch jobs. I'll create these in my home directory (sometimes aliased as ~), and will assume you have done the same.   good.sas: data _null_; run;   bad.sas: data _null_; mistake; run;   abort_abend.sas: data _null_; abort abend; run;   You can create these SAS programs any way you like. One way is to run this block of bash script, which creates the files in your home directory:   # Create a SAS program called good.sas which should run to completion with no errors tee ~/good.sas > /dev/null << EOF data _null_; run; EOF # Create a SAS program called bad.sas which should fail with errors tee ~/bad.sas > /dev/null << EOF data _null_; mistake; run; EOF # Create a SAS program called abort_abend.sas which should abort and abend tee ~/abort_abend.sas > /dev/null << EOF data _null_; abort abend; run; EOF   Let's also create one more program, borrowed from the SAS language documentation and from Bruno Mueller's post referenced below, which runs normally and produces some HTML output:   html.sas:   %let batchjobdir = %sysget(BATCHJOBDIR); ods _all_ close; ods html file="&batchjobdir/sashelp_weight_over_100.html"; title 'Student Weight'; proc print data=sashelp.class; where weight>100; run; ods html close;   Or, if you want to create it in a script or from the command line, run this:   # Create a SAS program called html.sas which should run to completion with no # errors and create HTML output, to a file in the batch job directory, where # it will be included in the fileset for the job as output. tee ~/html.sas > /dev/null << EOF %let batchjobdir = %sysget(BATCHJOBDIR); ods _all_ close; ods html file="&batchjobdir/sashelp_weight_over_100.html"; title 'Student Weight'; proc print data=sashelp.class; where weight>100; run; ods html close; EOF     Run a SAS program in batch   This SAS Viya CLI command will run the program good.sas as an asynchronous SAS batch job, meaning without waiting for the program to start or to finish. The ${sas_batch_options} part includes any options we defined earlier, and the --pgm-path parameter passes in the path to the SAS program file good.sas in your home directory:   sas-viya batch jobs submit-pgm ${sas_batch_options} --pgm-path ~/good.sas   The expected output is something like this:   >>> The file set "JOB_20241028_135406_321_1" was created. >>> Uploading "good.sas". >>> The job was submitted. ID: "043a625c-c8e7-4018-944f-85d787be0965" Workload Orchestrator job ID: "19"   When the command prompt returns, that doesn't necessarily mean the program has run, though in a SAS Viya deployment which is not busy, it might run within a few seconds. To find out if it has run, you need to query the batch job's status, and the command to do that takes the job ID as a parameter, like this:   batch_job_id="043a625c-c8e7-4018-944f-85d787be0965" sas-viya batch jobs list --job-id ${batch_job_id} --details   If everything is working and you run that command after the batch job has finished, the output should look something like this:   { "items": [ { "contextId": "e3c2bcde-49e7-4ed4-957c-b1b470e6ad32", "createdBy": "geladm", "creationTimeStamp": "2024-10-28T13:54:07.88399Z", "endedTimeStamp": "2024-10-28T13:54:15Z", "executionHost": "10.42.0.67", "fileSetId": "JOB_20241028_135406_321_1", "id": "043a625c-c8e7-4018-944f-85d787be0965", "modifiedBy": "anonymous", "modifiedTimeStamp": "2024-10-28T13:54:15.848773Z", "name": "good", "processId": "397b12ca-a280-4b73-af74-077cad34bf03", "returnCode": 0, "startedTimeStamp": "2024-10-28T13:54:07Z", "state": "completed", "submittedTimeStamp": "2024-10-28T13:54:07Z", "workloadJobId": "19" } ] }   You can perhaps see the state of the job (“completed”), and its return code (0) in that JSON output. So this is a good time for us to use jq to extract those values, and some others, and store them in variables for subsequent use in messages or decision logic.   If you pass a JSON document like the one above to the jq command which follows, it will find the first entry in the [items] array, and return the workloadJobID from that entry:   jq -r '.items[0]["workloadJobId"]'   The -r parameter (alternatively, --raw-output) writes the output string directly rather than as a JSON string with quotes.   We are ready to put this all together.       Store the status details of a SAS program in variables   The series of commands which follow will run the same sas-viya batch jobs list command as above, and redirect the output to a temporary file. The next few commands will each pass that file in to jq to have it select the values we are interested in from the JSON document.   In this example I've added a few more values to the set we retrieve from those details, in addition to the state and return code:   sas-viya batch jobs list --job-id ${batch_job_id} --details > /tmp/batch_job_details.txt batch_job_workload_job_id=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["workloadJobId"]') batch_job_workload_job_name=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["name"]') batch_job_state=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["state"]') batch_job_return_code=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["returnCode"]') batch_job_fileset_id=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["fileSetId"]')   Now we have those values about the state of the batch job, we can do whatever we wish with them. For example, we can print a message to the console (stdout) displaying the values to show it worked so far:   echo "Workload Job ID: \"${batch_job_workload_job_id}\" Name: \"${batch_job_workload_job_name}\" State: \"${batch_job_state}\" returnCode: \"${batch_job_return_code}\" fileSetId: \"${batch_job_fileset_id}\" "   Expected output is something like this:   Workload Job ID: "19" Name: "good" State: "completed" returnCode: "0" fileSetId: "JOB_20241028_135406_321_1"     Define functions to get the state of SAS batch jobs   So far so good, but running those commands interactively every time is tedious, so we will define some bash functions that will help us reduce repetition, and streamline the process of reporting on batch job state:   # Define a bash function to echo (print to console) the status details of a batch job # Usage: echo_batch_job_state ${batch_job_id} function echo_batch_job_state () { # sas-viya batch jobs list --job-id ${batch_job_id} --details | tee /tmp/batch_job_details.txt sas-viya batch jobs list --job-id ${batch_job_id} --details > /tmp/batch_job_details.txt batch_job_workload_job_id=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["workloadJobId"]') batch_job_workload_job_name=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["name"]') batch_job_state=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["state"]') batch_job_return_code=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["returnCode"]') batch_job_fileset_id=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["fileSetId"]') echo "Workload Job ID: \"${batch_job_workload_job_id}\" Name: \"${batch_job_workload_job_name}\" State: \"${batch_job_state}\" returnCode: \"${batch_job_return_code}\" fileSetId: \"${batch_job_fileset_id}\" " } # Define a bash function to echo the return code of a batch job function get_sasbatch_rc () { sas-viya batch jobs list --job-id ${batch_job_id} --details > /tmp/batch_job_details.txt batch_job_return_code=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["returnCode"]') echo ${batch_job_return_code} } # Define a bash function to echo the fileset ID associated with a batch job function get_sasbatch_fileset_id () { sas-viya batch jobs list --job-id ${batch_job_id} --details > /tmp/batch_job_details.txt batch_job_fileset_id=$(cat /tmp/batch_job_details.txt | jq -r '.items[0]["fileSetId"]') echo ${batch_job_fileset_id} }     Submit a SAS program asynchronously, and watch its progress   Now you can run this to submit a new batch job to run the SAS program good.sas again:   # Submit a good program as an asynchonous SAS batch job, and get the job ID pgm_name=good sas-viya batch jobs submit-pgm ${sas_batch_options} --pgm-path ~/${pgm_name}.sas | tee /tmp/batch_job_submission_response.txt batch_job_id=$(cat /tmp/batch_job_submission_response.txt | grep "ID:" | awk '{print $7}' | tr -d \")   As soon as you have submitted the batch job, run this repeatedly, until the job has completed:   echo_batch_job_state ${batch_job_id}   If you are quick, you might be able to see in the output it produces that the job is first pending, then running, and then completed. Expected output from our custom bash function echo_batch_job_state() during the successive stages of the SAS batch job running might look like these examples:   Workload Job ID: "21" Name: "good" State: "pending" returnCode: "0" fileSetId: "JOB_20241028_144729_489_1" Workload Job ID: "21" Name: "good" State: "running" returnCode: "0" fileSetId: "JOB_20241028_144729_489_1" Workload Job ID: "21" Name: "good" State: "completed" returnCode: "0" fileSetId: "JOB_20241028_144729_489_1"   The returnCode value remains 0 when the program has completed, indicating it ran successfully.       Examples with non-zero return codes   Let's run the next two programs in a similar way and see how the output of echo_batch_job_state()  differs.   bad.sas Here is how it looks with the intentionally 'bad' program:   # Submit a good program as an asynchonous SAS batch job, and get the job ID pgm_name=bad sas-viya batch jobs submit-pgm ${sas_batch_options} --pgm-path ~/${pgm_name}.sas | tee /tmp/batch_job_submission_response.txt batch_job_id=$(cat /tmp/batch_job_submission_response.txt | grep "ID:" | awk '{print $7}' | tr -d \")   As soon as you have submitted the batch job, run this repeatedly, until the job has completed:   echo_batch_job_state ${batch_job_id}   Output might look like this for bad.sas:   Workload Job ID: "23" Name: "bad" State: "pending" returnCode: "0" fileSetId: "JOB_20241028_150052_511_1" Workload Job ID: "23" Name: "bad" State: "running" returnCode: "0" fileSetId: "JOB_20241028_150052_511_1" Workload Job ID: "23" Name: "bad" State: "failed" returnCode: "2" fileSetId: "JOB_20241028_150052_511_1"   The return code of 2 indicates the job failed with errors. I think a return code of 1 is seen (or used to be, in earlier versions of SAS) after some kinds of SAS warning. But the handful of programs I tried which output warnings in their SAS logs, all had an exit code of 0 despite the warnings, which I recall meaning the warning is more for information and is not too serious. If you know better, or if you have an example of a SAS program which ends with an error code of 1, please let me know and I'll update this post to include it.   abort_abend.sas Here is how it looks with the program that aborts and ends abruptly:   # Submit program which aborts and abends as an asynchonous SAS batch job, and get the job ID pgm_name=abort_abend sas-viya batch jobs submit-pgm ${sas_batch_options} --pgm-path ~/${pgm_name}.sas | tee /tmp/batch_job_submission_response.txt batch_job_id=$(cat /tmp/batch_job_submission_response.txt | grep "ID:" | awk '{print $7}' | tr -d \")   As soon as you have submitted the batch job, run this repeatedly, until the job has completed:   echo_batch_job_state ${batch_job_id}   Output might look like this for abort_abend.sas:   Workload Job ID: "24" Name: "abort_abend" State: "pending" returnCode: "0" fileSetId: "JOB_20241028_150719_824_1" Workload Job ID: "24" Name: "abort_abend" State: "running" returnCode: "0" fileSetId: "JOB_20241028_150719_824_1" Workload Job ID: "24" Name: "abort_abend" State: "failed" returnCode: "5" fileSetId: "JOB_20241028_150719_824_1"   The return code of 5 indicates a more serious problem than just a syntax error, caused by the abort abend; statement in this SAS program.       Save the return code and output files produced by our SAS program   Seeing the status and return code on the console output is nice, but we can do more. First, we should store the return code of that batch job in a variable, like this:   batch_rc=$(get_sasbatch_rc ${batch_job_id})   That allows us to use the return code in decision logic. We can then download the fileset belonging to our batch job.     IMPORTANT: Downloading the fileset causes SAS Viya to stop listing the job and delete its fileset, so you can no longer get its return code (at least not as easily) after you download the fileset. Therefore, it is important to save the return code in a variable, e.g. using our get_sasbatch_rc() convenience function as shown above, BEFORE downloading the fileset.   The batch job fileset includes the .sas program file you submitted, any additional input files we passed in (there are none in these examples), the usual SAS program .log file and .lst output, and even additional files written to the batch job's fileset directory, as illustrated with the sample program html.sas above.   In this example, we download the fileset for the good.sas sample program to a directory below /tmp, named for the batch job fileset ID, and then we list the files in that directory to the console using ls:   # Download the results, i.e. the fileset - to a specific local directory. sas-viya batch jobs get-results --job-id ${batch_job_id} --results-dir /tmp # List the results files in that directory ls -l /tmp/${batch_job_fileset_id}   Here's an example directory listing using the statements above, after running good.sas:   total 12 -rwxr--r-- 1 cloud-user cloud-user 1513 Oct 28 11:17 good.log -rwxr--r-- 1 cloud-user cloud-user 18 Oct 28 11:17 good.sas -rw------- 1 cloud-user cloud-user 363 Oct 28 11:17 job.info   You can then view the program log file using your preferred text editor. To show it worked, this command will show a few lines of the good.log file:   head /tmp/${batch_job_fileset_id}/good.log   Example output:   1 The SAS System Monday, October 28, 2024 03:17:00 PM NOTE: Copyright (c) 2016-2023 by SAS Institute Inc., Cary, NC, USA. NOTE: SAS (r) Proprietary Software V.04.00 (TS M0 MBCS3170) Licensed to (SIMPLE) THIS ORDER IS FOR SAS INTERNAL USE ONLY, Site 70180938. NOTE: This session is executing on the Linux 3.10.0-1062.12.1.el7.x86_64 (LIN X64) platform. NOTE: Additional host information:   html.sas Now, let's run html.sas in the same way as before:   pgm_name=html sas-viya batch jobs submit-pgm ${sas_batch_options} --pgm-path ~/${pgm_name}.sas | tee /tmp/batch_job_submission_response.txt batch_job_id=$(cat /tmp/batch_job_submission_response.txt | grep "ID:" | awk '{print $7}' | tr -d \")   If you like, run this repeatedly, to watch the batch job progress through the pending and running states until it reaches the completed state:   echo_batch_job_state ${batch_job_id}   When it is completed, save the return code (remember, you can't do this after you download the fileset), and then download the fileset:   # Save the return code of the last batch job - this will no longer be # available after we download the results of that job batch_rc=$(get_sasbatch_rc ${batch_job_id}) # Download the results, i.e. the fileset - to a specific local directory. sas-viya batch jobs get-results --job-id ${batch_job_id} --results-dir /tmp # List the results files in that directory ls -l /tmp/${batch_job_fileset_id}   Expected output - notice we have the log file and also the HTML output file that our html.sas program creates, called sashelp_weight_over_100.html:   -rwxr--r-- 1 cloud-user cloud-user 2012 Oct 28 11:41 html.log -rwxr--r-- 1 cloud-user cloud-user 214 Oct 28 11:41 html.sas -rw------- 1 cloud-user cloud-user 363 Oct 28 11:41 job.info -rwxr--r-- 1 cloud-user cloud-user 37370 Oct 28 11:41 sashelp_weight_over_100.html   We can then view the first few lines of the HTML file as text:   head /tmp/${batch_job_fileset_id}/sashelp_weight_over_100.html   Expected output – this certainly looks like HTML generated by SAS code:   <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta name="Generator" content="SAS Software Version V.04.00, see www.sas.com"> <meta http-equiv="Content-type" content="text/html; charset=utf-8"> <title>SAS Output</title> <style type="text/css"> <!-- .accessiblecaption {   Here's a screenshot of the (full) HTML file opened in a web browser:    HTML output produced by example program html.sas.     Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.     Use the return code for decision logic   You could use the return code to drive a decision step in your workflow, about whether to continue with the next step, or which step to run next. Here is an example using more bash shell statements - though again, I haven't managed to get an example SAS program which actually does result in a return code of 1, but I think this illustrates the idea. You will want to write something similar that better suits your own requirements:   # If the return code is 0, list the first lines of the output html file if [ "${batch_rc}" == "0" ]; then echo "The batch job succeeded." echo echo "Here are the first few lines of the output html file:" head /tmp/${batch_job_fileset_id}/sashelp_weight_over_100.html elif [ "${batch_rc}" == "1" ]; then echo "The batch job finished with important warnings." elif [ "${batch_rc}" == "2" ]; then echo "The batch job finished with errors." else echo "The batch job finished with return code of ${batch_rc}." fi     Get the return code from synchronous batch jobs (that specify --wait)   When you submit a batch job with the --wait parameter, then instead of returning control to the command line or continuing to the next step in your script when the batch job is submitted, the sas-viya batch jobs submit-pgm command waits for the batch job to finish running.   The method for getting the return code from a SAS batch job run synchronously with --wait is similar to the method getting it from an asynchronous batch job. Here's an example, which needs little explanation if you have read this far:   # Submit a program which produces HTML output as a SAS batch job, wait for it to complete, and get the status and return code pgm_name=html sas-viya batch jobs submit-pgm ${sas_batch_options} --pgm-path ~/${pgm_name}.sas --wait | tee /tmp/batch_job_output.txt batch_job_id=$(cat /tmp/batch_job_output.txt | grep "ID:" | awk '{print $7}' | tr -d \") echo_batch_job_state ${batch_job_id} ########################################## ## Download the batch job logs (once only) ########################################## # Get details of the job's output fileset batch_job_fileset_id=$(get_sasbatch_fileset_id ${batch_job_id}) echo $batch_job_fileset_id # List files in this job's fileset sas-viya --output text batch filesets list-files --id ${batch_job_fileset_id} # Save the return code of the last batch job - this will no longer be # available after we download the results of that job batch_rc=$(get_sasbatch_rc ${batch_job_id}) # Download the results, i.e. the fileset - to a specific local directory. sas-viya batch jobs get-results --job-id ${batch_job_id} --results-dir /tmp # List the results files in that directory ls -l /tmp/${batch_job_fileset_id} # If the return code is 0, list the first lines of the output html file if [ "${batch_rc}" == "0" ]; then echo "The batch job succeeded." echo echo "Here are the first few lines of the output html file:" head /tmp/${batch_job_fileset_id}/sashelp_weight_over_100.html elif [ "${batch_rc}" == "1" ]; then echo "The batch job finished with important warnings." elif [ "${batch_rc}" == "2" ]; then echo "The batch job finished with errors." else echo "The batch job finished with return code of ${batch_rc}." fi   We have demonstrated how to run SAS programs as batch jobs, asynchronously and synchronously, how to monitor their progress, and how to get both their returnCode indicating success or failure, and their log files, all from the command line using shell script.   This post would have been much more difficult to write without the great SAS documentation, and the posts on closely related topics written by Gerry Nelson, Bogdan Teluca and Bruno Mueller. My thanks to all three for their work, referenced below.       References and resources   SAS Help Center documentation references:   SAS Viya Command-Line Interface documentation: Command-Line Interface: Overview, Command-Line Interface: Instructions When Running the CLI from a Container Documentation for the SAS Batch Command-Line Interface specifically: SAS Batch CLI Using the Output Delivery System (ODS) to create HTML and other formats of output in SAS code: Getting Started with the Output Delivery System   Gerry Nelson wrote a couple of posts on installing and configuring the SAS Viya Command-Line Interface natively or in a container, for any of its many use cases (not specifically just SAS batch jobs):   SAS Viya Command-Line Interface for Administration (update), in which Gerry explains the overall installation and initial configuration of the SAS Viya CLI and gives some simple examples of administrative tasks you can use it for in general. Overview of installing and using the SAS Viya containerized CLI with SAS Viya LTI 2024.03 and later, Gerry explains how to download and use the SAS Viya CLI in a pre-built container image from SAS, which simplifies automation, and reduces the need for pre-requisite components. He also shows how to build your own custom docker image, using the SAS supplied image as a starting point and adding your own tools to it - he adds git and our pyviyatools project as an example. Bogdan Teleuca has written an introductory post for readers who are new to the SAS batch command line: In How to Run SAS Programs in Batch in the New SAS Viya Bodgan explains the basics of running SAS batch jobs from the SAS Viya Command-Line Interface (sas-viya CLI) in SAS Viya 2020.1 and later. He walks through configuring the SAS Viya CLI, setting up a profile for the CLI defining the REST endpoint that the CLI will connect to, where the TLS certificates are, preferred output options, and authenticating to SAS Viya as a specific user. He then shows how to run a .sas program synchronously through the SAS batch CLI, streaming the SAS log output to your console.   Bruno Mueller wrote this really nice post about sas-viya batch jobs, file sets and the SAS administrator, which is a great introduction to the topic, and from which I 'borrowed' some ideas.   And finally, if you are using Apache Airflow or Argo Workflow, I highly recommend these posts by Gerry Nelson:   Using Apache Airflow to automate SAS Viya administration tasks, which in turn references SAS administration command-line interface in a container: Part 1 Docker SAS administration command-line interface in a container: Part 2 Kubernetes and Argo Workflow   See you next time! ... View more

Watch this Ask the Expert session to understand the role of a SAS Viya administrator and build confidence and improve the configuration, stability, and performance of your SAS Viya deployment.    Watch the webinar   You will learn: The role of a SAS Viya administrator. Which parts of SAS Viya administration are relevant to your role. How to use a checklist of SAS Viya administration tasks The questions from the Q&A segment held at the end of the webinar are listed below and the slides from the webinar are attached.   Q&A Can I contribute new tasks? At the top of the checklist, there's a link to the project README.md (https://github.com/sassoftware/viya4-admin-checklist/blob/main/README.md). Inside that, we have lots of orientation information about the project. You don't need to read all of this before you start, but it can be quite helpful. Within that, we've got a Contributing section, that has a link to a document that describes how to contribute new tasks. There is a fairly simple contributor agreement to that, nothing too onerous. It describes how to go about creating your own task or modifying an existing task and then submitting a pull request. If you can provide a version of the file in any form to us, including as a GitHub pull request, we'll happily look at it. We can review and edit it if needed, and would be delighted for contributions.   How should I suggest ideas for things to include in the checklist? In GitHub, there is an Issues feature. You can raise an issue, and that is a fantastic way to get in touch with the current maintainers of the project. We'll see the issue come in, we get an e-mail notification, and then we can discuss what you'd like, whether that's a suggestion or if you see a problem with something that you'd like us to revise or write new content or change existing content. If you use a GitHub issue, that's probably the quickest way to get in touch with us. You can also get in touch with the individual project team members, but that's a bit more of an unreliable way to do it because over time we may move teams, we may be working on other projects and not be quite as responsive. So, a GitHub issue is absolutely the best way to get in touch.   Regarding Authorization Model: is it possible not only to import Identities from the identity provider but also the organizational groups, roles, etc. in SAS Viya? Currently, we have different SAS 9.4 environments running which are almost fully driven by AD groups: users, user groups, roles, the folder/library creation and access rules (R/W) are driven by AD, new users, users leaving/moving in the organization, ownership of data,… ACT's together with ACL's on Linux level (enhancements to macro's provided by SAS Institute). Is such a setup easy migratable/feasible from SAS 9.4 towards SAS Viya? Well, that is a fantastic question, bravo. Short answer, some bits yes and some bits no. Let's split those out a little bit and we may follow up with this one in the post session material as well.   First of all, about the users and groups. The way that users and groups are managed in SAS 9 is different to the way that it happens in SAS Viya. In SAS 9, you have to do something as the SAS administrator to extract the current list of users and groups from your identity provider, typically Entra ID, Active Directory, or something like that. You have to run some code that will maintain the list of users and groups in your SAS 9 environment in the metadata. SAS Viya doesn't work like that. SAS Viya uses either SCIM, or the Identities service to pull identities from an LDAP provider like Entra ID or some other LDAP provider, OpenLDAP maybe, and it will [do so] automatically. Well, when the identity server pulls users and groups from LDAP, it's a pull model. When you use SCIM to provide identities to SAS Viya then that's a push model. The updates are initiated from the external identity provider. But either way around, what you get is an automatically maintained list of users and groups in SAS Viya. So, you don't need to run something yourself anymore to create them in SAS Viya. And yes, the groups that those users are in will come through if you configure the identity service to pick those groups up correctly. So, part of the job of the initial configuration of your environment is that initial configuration of the identity service so that you get the groups you need and ideally not too many of the groups you're not interested in.   Regarding the part of your question about the ACTs (Access Control Templates) in SAS 9, which are commonly used for securing all kinds of resources in SAS 9, and ACLs which is Access Control Lists on the Linux file system, there is a two-part answer.   The authorization models in SAS Viya are a General Authorization system, used for most things like folders, reports, and application functionality. CAS (Cloud Analytic Services) has its own separate authorization system. But both of those are really quite different to the metadata authorization in SAS 9. So, there is no easy way to automate the translation of the permissions that you have on objects in SAS 9 with ACTs. There's no easy way to automate the conversion of that through to SAS Viya. I've seen lots of people attempt it with varying degrees of success, but it's not a simple, pain-free process. I would expect to have to redesign an authorization system from scratch in SAS Viya based on the same principles as the one you had in SAS 9. But the way [permissions are] implemented in SAS Viya is so different that you can't easily automate the transfer of a SAS 9 authorization system into a SAS Viya one.   The last part you'd touched on was, I think Access Control Lists on the Linux file system. They work the same in SAS Viya (if you're using a POSIX style file system) as they did in SAS 9. All you need to do is make sure that your CAS sessions, or your Programming Runtime sessions are running as the right user. So, when the attempt is made to access something on the file system in that directory structure with those permissions applied to it, it's being accessed as the correct user and not as some service account. But beyond that, it should work more or less the same way that it did with SAS 9.   Is it possible to access and apply these ten points? I'm not totally sure if I know what you mean by that. I mean the list of the 10 tasks that we've picked was indicated by that ‘Essential’ column in the main Checklist, and in the Regular Tasks Checklist. So that's where you can access them. I guess we don't have anything that we provide that's an automated method for designing your backup and restore process, or for designing your authorization model for you. Some of these are higher level design tasks or administrative activities that we can't script.   Can you please share procedure to migrate SAS Viya 3.5 to Viya 4? https://go.documentation.sas.com/doc/en/sasadmincdc/v_054/calmigration3x/n06wplu5iqmgz6n1mnpklw71eyvw.htm   How frequently do we need to install hotfix in SAS Viya? That is up to you. There is an Update Checker report that runs daily which will inform you of the availability of updates. You can then choose to apply the updates at your convenience. Viya Stable releases come out monthly, so we find most customers apply updates at least weekly.   How to convince customers to migrate to SAS Viya from Sas 9.4? Because lot of customers/clients moving to other clouds from SAS 9.4 compared to SAS Viya. This overview of SAS Viya may help https://go.documentation.sas.com/doc/en/calintro/v_001/p0l5bvopo6rhuqn1nw7frbipj7lo.htm   Does SAS support local internal registry for mirror registry? Yes, it does. There is documentation available for that in the SAS Viya Operations Guide (https://go.documentation.sas.com/doc/en/itopscdc/default/dplyml0phy0dkr/p1cq2mti42s7lkn1wl4pfwyq45up.htm)   Do we need any Kubernetes admin knowledge for SAS Viya admin? Yes, that is quite essential. You may not need to be a K8s admin, but it will be helpful to be aware of their duties to communicate effectively with them.   Is there SAS -nodms session launch in SAS Foundation in SAS Viya 4? Yes, you can use the sas-viya command to get something similar for SAS Viya. The command would be like this: sas-viya batch jobs run-saslm -c <context>   What if the cloud admin asks to take all images in single repository in AWS? Is it possible to store all images in a single repository? You can setup a mirror repository and store the Viya images in that repository.     Recommended Resources SAS Viya Administration Checklist SAS Viya 3.5 Administration Checklist Top 10 Platform Administration Tasks Checklist of SAS® Platform Administration Tasks SAS Administration Learning Subscription, SAS Viya Platform topic: 5 courses leading to Administering SAS Viya exam Please see additional resources in the attached slide deck.   Want more tips? Be sure to subscribe to the Ask the Expert board to receive follow up Q&A, slides and recordings from other SAS Ask the Expert webinars. ... View more

SAS Viya Monitoring for Kubernetes' log monitoring stack collects log messages and stores them in its own instance of OpenSearch. At the latest release, version 1.2.21, its command-line tool getlogs.py has been moved to 'production' status.   getlogs.py is a tool for exporting log messages captured in the log monitoring OpenSearch instance to a file or to the console/stdout, formatted as either CSV or JSON. Use it interactively from a command line or a script. Filter criteria and/or a search string can be specified as command parameters, or you can download, edit, and resubmit log queries written in OpenSearch's built-in domain-specific language (DSL) query syntax, to get the specific log messages you are interested in.   In this post, I'll describe my initial experiences setting up and using getlogs.py. The documentation already includes some nice usage examples - I'll add a few of my own too. In a follow-up post, I'll explore downloading, modifying and re-uploading a query with getlogs.py, to see how easy it might be to exploit the richness of the OpenSearch built-in query language from a script.     Prerequisites for getlogs.py   The documentation for getlogs in SAS Help Center lists two requirements: Python 3.11 or later, and an OpenSearch module for python, opensearch-py. Obviously, you'll also need a running instance of the log monitoring stack from SAS Viya Monitoring for Kubernetes version 1.2.21 or later, and a way to access it over the network. This can be either: An ingress for the OpenSearch back-end data store (note this is separate from the OpenSearch Dashboards ingress you might use to access the front-end web application), or A kube config file, giving access to the Kubernetes cluster and the logging namespace where OpenSearch is running, which getlogs.py can use to set up temporary port-forwarding to give it a network path to the OpenSearch back-end data store Python 3.11   If you have a relatively recent version of Linux to deploy the tools on, the Python 3.11 prerequisite and its dependencies is unlikely to be an issue. A quick web search will turn up plenty of guides to installing Python 3.11 if yours is a slightly older version.   During my initial attempts it turned out that the Python 3.11 requirement took more effort to satisfy, because the version of Linux we use for our workshop environments is a little (ahem) 'mature', and didn't have Python3.11 available in its usual package manager. Python3.11's dependency on openssl 1.1.1 was tricky to meet without impacting other components running on the same Linux host that my workshop Kubernetes cluster and SAS Viya were running on (upgrading OpenSSL to a major release that was later than everything else in that Linux release expected broke other services). So I used a separate Linux host to experiment with getlogs.py: an instance of Ubuntu Linux running in WSL (Windows Subsystem for Linux) on my Windows desktop. Since the Ubuntu release running in my WSL was more recent, it already had a suitable version of openssl which meant deploying Python 3.11 was simple (and didn't break anything else). I had no problem getting the opensearch-py Python module installed in either scenario.   Network path to OpenSearch from the host where you run getlogs.py   getlogs.py offers two ways to define a network path from your client machine to the back-end OpenSearch data store. OpenSearch ingress   The samples included with SAS Viya Monitoring for Kubernetes include alternative user-values-opensearch.yaml files illustrating how to set up an ingress for OpenSearch.   To configure host-based ingress like https://opensearch.your-ingress-controller-hostname-or-alias/, see https://github.com/sassoftware/viya4-monitoring-kubernetes/blob/1.2.21/samples/ingress/host-based-ingress/logging/user-values-opensearch.yaml, samples/ingress/host-based-ingress/logging/user-values-opensearch.yaml. To configure path-based ingress like https://opensearch.your-ingress-controller-hostname-or-alias/, see samples/ingress/path-based-ingress/logging/user-values-opensearch.yaml.   If the user-values-opensearch.yaml file in your USER_DIR directory struture has extra attributes like those illustrated in your chosen sample, Kubernetes will set up the corresponding type of ingress for OpenSearch when you deploy the log monitoring stack.   I noted that I could only get an ingress to OpenSearch working properly if I enabled TLS (HTTPS) for it. I got an http 503 bad gateway error when I tried without TLS/HTTPS. Internally, OpenSearch's network access is always over TLS/HTTPS anyway, and it was no problem for me to configure it with HTTPS, so I just did that. Maybe there is a way to get it working without TLS, but I didn't try that particularly hard.   Prior to testing getlogs.py worked, for convenience, I exported four environment variables: OSUSER, OSPASSWD - OSHOST and OSPORT, as illustrated in the documentation under Connect to OpenSearch with Direct Link to Host, so I didn't have to keep telling getlogs.py how to get to OpenSearch with command line parameters, which are the alternative: # Try getlogs.py cd ~/viya4-monitoring-kubernetes/ export OSUSER=admin export OSPASSWD=mysecretadminpassword export OSHOST=opensearch.hostname.something-or-other.com export OSPORT=443 python3.11 logging/bin/getlogs.py If you don't create your own signed certificate for the TLS connection and provide it in the secret named in that yaml file, I think OpenSearch creates its own self-signed certificate. But your browser/command line client might not trust a self-signed certificate, so I prefer to provide one I know is trusted, and avoid that issue. I didn't play around with that very much though. Port forwarding   The other option, attractive if you prefer not to (or cannot) create an ingress to your log monitoring OpenSearch instance, or if you prefer not to pass a username and password to getlogs.py on the command line, is to provide a kube config file that gives access to the logging namespace in your Kubernetes cluster where that OpenSearch instance runs. Save the kube config file somewhere on a file system accessible to the host where you will run getlogs.py, set a KUBECONFIG environment variable to point to it, and run getlogs.py with a -pf parameter as shown below: # Try getlogs.py cd ~/viya4-monitoring-kubernetes/ export KUBECONFIG=~/.kube/config python3.11 logging/bin/getlogs.py -pf This tells getlogs.py to set up a temporary Kubernetes port-forward to use while it queries the OpenSearch data store. In some situations this may be considered more secure - I like that we have a choice.   Default output   Whichever method you use to set up a network path to OpenSearch, with no other parameters on the command line getlogs.py should return the 10 most recently captured log messages, from any logsource/container/pod/namespace, within the past 1 hour, in CSV format. They should look something like the example below - the content will vary depending on what log messages your SAS Viya Monitoring for Kubernetes log monitoring stack most recently happened to capture and stream through to OpenSearch: Searching index: Search complete @timestamp,level,kube.pod,message,_id 2024-02-01T12:58:33.928Z,NONE,canal-qpqww,"2024-02-01 12:58:33.928 [INFO][25162] monitor-addresses/startup.go 432: Early log level set to info ",67065E0E-9E9D-8806-E822-6158E3EACB78 2024-02-01T12:58:33.928Z,NONE,canal-qpqww,"2024-02-01 12:58:33.928 [INFO][25162] monitor-addresses/startup.go 315: Skipped monitoring node IP changes when CALICO_NETWORKING_BACKEND=none ",6C44C501-E7C8-F6ED-1617-FF5CE3E0BA65 2024-02-01T12:58:33.923Z,WARNING,canal-qpqww,Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.,02BD6FBB-6453-CB17-3658-E5A2AF060D92 2024-02-01T12:58:33.870Z,NONE,canal-wkthm,"2024-02-01 12:58:33.870 [INFO][27083] monitor-addresses/startup.go 432: Early log level set to info ",C32FA169-A498-3410-850B-478F16F9B962 2024-02-01T12:58:33.870Z,NONE,canal-wkthm,"2024-02-01 12:58:33.870 [INFO][27083] monitor-addresses/startup.go 315: Skipped monitoring node IP changes when CALICO_NETWORKING_BACKEND=none ",D3BED951-D4B0-911C-0F8E-B19E62C17EFF 2024-02-01T12:58:33.867Z,WARNING,canal-wkthm,Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.,4148E479-215D-7056-9318-85368F213D76 2024-02-01T12:58:33.564Z,NONE,canal-q87j6,"2024-02-01 12:58:33.564 [INFO][11868] monitor-addresses/startup.go 432: Early log level set to info ",418CE3BC-B3D4-F13B-C653-32F3A5914F79 2024-02-01T12:58:33.564Z,NONE,canal-q87j6,"2024-02-01 12:58:33.564 [INFO][11868] monitor-addresses/startup.go 315: Skipped monitoring node IP changes when CALICO_NETWORKING_BACKEND=none ",E8E10D1B-74A3-7437-B1E4-952B796E9A69 2024-02-01T12:58:33.561Z,WARNING,canal-q87j6,Setting GA feature gate ServiceInternalTrafficPolicy=true. It will be removed in a future release.,7A4738E1-4196-0FC9-0ABE-EFC504A6C3D5 2024-02-01T12:58:33.123Z,NONE,canal-fs4vm,"2024-02-01 12:58:33.123 [INFO][20724] monitor-addresses/startup.go 432: Early log level set to info ",0E4A2CC2-64FA-C1FD-6235-6943512FC1F0 This serves as a reasonably good validation test that both getlogs.py and your network path (via ingress or port-forwarding) to OpenSearch are configured correctly, and that all of the pre-requisites are met.   If you get an error message instead of log output, you'll need to debug the issue before you proceed.   Syntax help   Like many command-line tools, getlogs.py -h outputs help text, describing the parameters it takes: python3.11 logging/bin/getlogs.py -h The parameters fall into three main categories, query search parameters that specify what log messages you want to see, query output parameters that influence the command's output (max rows, whether to a file, CSV or JSON etc.), and connection settings used when you don't set environment variables to provide those values. The start and end time parameters ( -st | --start [DATETIME ...] and -en | --end [DATETIME ...] ) are listed under query output settings, but I consider them more query search parameters.   Time Zones   The datetime values you pass in to the --start and --end parameters (examples towards the end of this post) should be in the local time zone that your host is configured to use. So for example if your host Linux machine is set to Eastern Standard Time (EST), you would specify the start and end times for the period you want to get log messages in the same time zone - EST.   However, the datetime values in the @timestamp column in getlogs.py's CSV output are in UTC (Universal Coordinated Time). So for example if you run getlogs.py on a host machine whose local time is EST to request log messages from between 13:00 and 14:00 EST, you should expect results showing log messages with timestamp values between 18:00 and 19:00 UTC time (since EST is 5 hours earlier than UTC). Remember to take this into account when specifying start and end time filters, and when viewing/storing log message output that contains a timestamp column from getlogs.py - it is a potential source of slight confusion.   Using getlogs.py with filter and search parameters   Namespace The first thing we will usually do is add a namespace parameter, to get log messages from the SAS Viya platform and any solutions deployed in it. My SAS Viya namespace is gelcorp (and I've set up an ingress and the environment variables to use it and authenticate as 'admin') so for me the command becomes: python3.11 logging/bin/getlogs.py -n gelcorp I noticed that the response time of queries was significantly longer with this parameter, but otherwise it works as expected.   Specify Output Fields (_id is always appended)   By default, CSV output from getlogs.py has the following fields: @timestamp,level,kube.pod,message,_id - the actual fields output for any particular results are printed in a header row before the results. I'm not sure why kube.pod was chosen instead of logsource. The _id field is always output, and it is always appended to the end of each CSV result.   Note: If you specify the _id field as one of the values of the --fields parameter, it is output in the results both in the position you specify, and also at the end of each row. There is thus little point in specifying the _id field as one of the values to the --fields parameter, unless for some reason you MUST have it at a particular position. You'll get it anyway at the end of reach row, regardless.   The saved search I usually open first on the Discover page in OpenSearch Dashboards is called Log Messages. We can imitate it in getlogs.py with --fields @timestamp level logsource message . (Again, the log document _id will be appended to the end of each results row without us asking for it, and we can't suppress it.): python3.11 logging/bin/getlogs.py -n gelcorp --fields @timestamp level logsource message Example results (just showing the first row, for the format - there were 10 rows of results): Searching index: Search complete @timestamp,level,logsource,message,_id 2024-02-01T15:27:36.583Z,INFO,workload-orchestrator,"The job ""1832"" has finished with exit code 0.",37FD93EA-33B6-8986-8AAD-9ABAB4114594 Search for a string   To create some log messages with a distinctive message in them, I opened SAS Studio, and ran the following line of SAS code, once to begin with: %put The quick brown fox jumped over the lazy dog; Having run that code in a compute session in SAS Studio, the compute server process writes out at least one line of log message containing that string to its container (and thus pod) logs. We should be able to find it with getlogs.py, like this: python3.11 logging/bin/getlogs.py -n gelcorp --fields @timestamp level logsource message --search 'The quick brown fox jumped over the lazy dog' Here is the same command, split over several lines with backslash line-continuation characters make it a little easier to read: python3.11 logging/bin/getlogs.py \ -n gelcorp \ --fields @timestamp level logsource message \ --search 'The quick brown fox jumped over the lazy dog' Here's the output from running that command (in either the single-line or multi-line form above - they are identical) on my environment. There are two lines of results - two matching log messages in the gelcorp namespace: Searching index: Search complete @timestamp,level,logsource,message,_id 2024-02-01T15:37:14.678Z,INFO,compsrv,80 %put The quick brown fox jumped over the lazy dog;,ABF69779-B0DE-61B7-8ED8-A287D0395576 2024-02-01T15:37:14.678Z,INFO,compsrv,The quick brown fox jumped over the lazy dog,2CD44B04-7E74-7DD1-4A31-8AD54230426F One log message is the SAS log output echoing the line it is running. The second is the result of running it - the text we asked SAS to '%put' into the program log.   Tip: If you want to check the @timestamp values in the results you see are for the correct time period, even though they are given in UTC time, you may wish to check the abbreviated name of the time zone that your host machine is set to use, and the offset that time zone has from UTC, which is used for the timestamps in the results. From a bash prompt, run date +%Z (with a capital Z ) to report your host machine's time zone's abbreviation, e.g. EST , according to the notation used by your host OS. Also, you can run date +%:z (with a lowercase z ) to report your host machine's time zone offset from UTC, e.g. -05:00 , which means this host's time zone is five hours behind UTC.   Time period   getlogs.py outputs messages from the last 1 hour by default. It doesn't (yet) have parameters to specify other relative time spans, like 'last 15 minutes' or 'last 24 hours', but bash has a date tool can do date calculations and format dates as we require them. This article was very helpful in writing the examples which follow below: https://www.unix.com/tips-and-tutorials/31944-simple-date-time-calulation-bash.html   Using the --start and --end parameters to getlogs.py, you can specify a custom relative time period fairly easily. Both parameters take a date time string in the format Y-M-D H:M:S , for example: 2024-02-01 15:00:00 .   Results for the last 15 minutes   We add some bash statements to calculate the time now and 15 minutes ago, and format these two times as getlogs.py expects: datetime_now=$(date "+%Y-%m-%d %T") echo ${datetime_now} datetime_15mins_ago=$(date --date "${datetime_now} 15 minutes ago" "+%Y-%m-%d %T") echo ${datetime_15mins_ago} # Log messages containing a specific string from gelcorp namespace in the last 15 minutes python3.11 logging/bin/getlogs.py \ -n gelcorp \ --fields @timestamp level logsource message \ --search 'The quick brown fox jumped over the lazy dog' \ --start ${datetime_15mins_ago} --end ${datetime_now}   Because more than 15 minutes (but less than 1 hour) had passed between the last time I ran my one-line SAS program to put that distinctive message in the logs, and when I first ran the code above, this output was correct:   Searching index: No results found for submitted query.   If you include the --search parameter to look for messages containing a specific string, and filter to e.g. the last 15 minutes, you won't see any results if the string has not appeared in any log messages in the last 15 minutes! That's correct.   We could either fix that by increasing the time period, or running the code again. I chose to try the latter first, and ran the same one-line SAS program again to have another, more recent log message containing that distinctive string. Then, I re-ran the same block of bash code above, and with more interesting results - the rows are similar to ones we saw in earlier output, but the timestamps and IDs are different:   Searching index: Search complete @timestamp,level,logsource,message,_id 2024-02-01T16:17:27.010Z,INFO,compsrv,80 %put The quick brown fox jumped over the lazy dog;,AD8056A4-81E2-97D6-3CCA-875A04B0E0A8 2024-02-01T16:17:27.010Z,INFO,compsrv,The quick brown fox jumped over the lazy dog,124E81F5-7BDC-8DB4-FB92-3EBD91A7E6F3   Results for the last 2 hours   Increasing the time period we search for to the past 2 hours, by modifing the bits of bash script before the call to getlogs.py, we expect to see both sets of results: datetime_now=$(date "+%Y-%m-%d %T") echo ${datetime_now} datetime_2hrs_ago=$(date --date "${datetime_now} 2 hours ago" "+%Y-%m-%d %T") echo ${datetime_2hrs_ago} # Log messages containing a specific string from gelcorp namespace in the last 2 hours python3.11 logging/bin/getlogs.py \ -n gelcorp \ --fields @timestamp level logsource message \ --search 'The quick brown fox jumped over the lazy dog' \ --start ${datetime_2hrs_ago} --end ${datetime_now} Results as expected - two pairs of rows matching our search string, one pair from within the last 15 minutes, and a pair from about 40 minutes earlier: Searching index: Search complete @timestamp,level,logsource,message,_id 2024-02-01T16:17:27.010Z,INFO,compsrv,80 %put The quick brown fox jumped over the lazy dog;,AD8056A4-81E2-97D6-3CCA-875A04B0E0A8 2024-02-01T16:17:27.010Z,INFO,compsrv,The quick brown fox jumped over the lazy dog,124E81F5-7BDC-8DB4-FB92-3EBD91A7E6F3 2024-02-01T15:37:14.678Z,INFO,compsrv,80 %put The quick brown fox jumped over the lazy dog;,ABF69779-B0DE-61B7-8ED8-A287D0395576 2024-02-01T15:37:14.678Z,INFO,compsrv,The quick brown fox jumped over the lazy dog,2CD44B04-7E74-7DD1-4A31-8AD54230426F   I think this is a good point to wrap up this post - we have not explored all of the filters that getlogs.py offers, so I'd encourage you to look at the output of getlogs,py -h, or explore the great usage examples in the getlogs.py documentation.   I am looking forward to seeing the applications we can put this valuable tool to, with scheduled scripts to extract log data for auditing and monitoring purposes. In a follow-up post, I intend to explore what we can do with the OpenSearch domain-specific query language that getlogs.py can use. There's a lot of potential value in this tool, and I hope you find it as useful as I think it is going to be.   See you next time!   Find more articles from SAS Global Enablement and Learning here. ... View more

Last time, in the first part of this two-part post I showed how to (mostly) manually create a new group-specific compute context, with permissions set up so that users only see group- or user-specific compute contexts they can use. We ran a one-time preparatory script that ensured all users could still see the original 'out-of-the-box' compute contexts.   This time, we will automate the steps and iterate through lists of groups and users to perform them, so you can scale up and create a larger number of group- and user-specific contexts. This would be tedious to do manually.   As we will seen, this makes it easy to create contexts which the SAS Administrator can then customize per group, or per user, to configure each with their own group-specific set of SAS options and autoexec statements. Yet users won't find their compute contexts menu in SAS Studio or SAS Model Studio cluttered with contexts they cannot (and are not supposed to be able to) use.   As before, we are going to use bash scripting and the sas-viya CLI. For this task you will again need the sas-viya CLI and its plugins, configured with a connection profile and certificates to connect to your SAS Viya cluster, and you must authenticate the sas-viya CLI as a member of the SAS Administrators custom group before proceeding.   Preparatory script already presented in part 1   In part 1, we already saw how to run an example bash script which uses the sas-viya CLI to:   Disable the rule granting Authenticated Users read access to all compute contexts ( /compute/contexts/* ), if it is not already disabled List all existing compute contexts, and store the list in a file Get the existing compute context IDs from that file, and iterate through them For each existing compute context, create a new authorization rule to grant all Authenticated Users read access to it   I won't duplicate that script here. Before continuing, if you have not done so in your SAS Viya environment already, please review, adapt and run that script as a one-time task.   In the results section of this post, I will also assume that you have been through the manual steps in part 1 to create a group-specific compute context for HR, and will include that in the expected results where appropriate.   Bulk-create group-specific and user-specific compute contexts   In part 1, we also manually created one new compute context, for the HR group in our example environment. We named it "SAS Studio compute context for HR group".   Now we can scale this up a bit. It is much quicker to use a bash script and the sas-viya CLI signed in as a SAS Administrator if you need to make a set of group- (or user-) specific compute contexts.   The create_contexts.sh script shown below is an example, but you will need to adapt it to your own needs, in at least these ways: You can choose which compute context you will use as your template – here I have chosen the SAS Studio compute context, but you can use a different one. Here I deliberately did not choose a context with a limitation already set on which identities – which users and groups – can create a compute session under that context. A reader comfortable with the process could quite easily modify the code to be based on a template which does add this restriction. Keep or delete whichever parts of the group-specific or user-specific context creation you need. The sample script below has both, but feel free to delete one  or the other. (Suggestion: follow better practices and only use the group-specific part!) Obviously, you will need to substitute the values in group_list and/or user_list with lists of IDs (rather than the names) of groups and users in your environment, for whom you wish to create specific compute contexts: group_list='Finance Sales' user_list='Henrik Fiona Sean' Uncomment the ls and rm statements in the last two lines if you want to have a record of, and then clean up the temporary files this script creates in the /tmp directory. I like to be able to inspect the temporary files, so I commented those lines out.   Do this in a non-production environment first. There is no 'undo' script, so reversing these changes could take some effort.   Copy the following code, and save it as a new script file called ~/create_contexts.sh . The comments in the code below explain what each bit does: #!/bin/bash # Download the JSON definition for the original SAS Studio Compute Context # and use jq to remove everything except the fields specified below. # The fields we select in jq should be the only fields we need. rm -f /tmp/sas-studio-context-template.json sas-viya --output fulljson compute contexts show -n "SAS Studio compute context" | \ jq 'with_entries(select(.key | in({"attributes":1, "description":1, "environment":1, "launchContext":1, "launchType":1, "name":1, "version":1})))' > /tmp/sas-studio-context-template.json cat /tmp/sas-studio-context-template.json # Set up the lists of users and groups we will create contexts for group_list='Finance Sales' user_list='Henrik Fiona Sean' for group in ${group_list} do rm -f "/tmp/sas-studio-context-${group}.json" cp "/tmp/sas-studio-context-template.json" "/tmp/sas-studio-context-group-${group}.json" sed -i -e 's/"name":.*,$/"name": "SAS Studio Compute Context for '${group}' group",/g' "/tmp/sas-studio-context-group-${group}.json" sed -i -e 's/"description":.*,$/"name": "Compute context to be used for the SAS Studio service by '${group}' group",/g' "/tmp/sas-studio-context-group-${group}.json" # Use the template to create a new context for this group sas-viya compute contexts create -r -d @/tmp/sas-studio-context-group-${group}.json > /tmp/new-context-created.json id=$(cat /tmp/new-context-created.json | jq -r '.id') # Grant the group permission to see their new context sas-viya authorization grant --group ${group} --permissions read --reason "${group} can read their own compute context" --object-uri "/compute/contexts/${id}" # Grant the group permission to create sessions under their new context sas-viya authorization grant --group ${group} --permissions create --reason "${group} can create sessions under their own compute context" --object-uri "/compute/contexts/${id}/sessions" done for user in ${user_list} do rm -f "/tmp/sas-studio-context-${user}.json" cp "/tmp/sas-studio-context-template.json" "/tmp/sas-studio-context-${user}.json" sed -i -e 's/"name":.*,$/"name": "SAS Studio Compute Context for '${user}'",/g' "/tmp/sas-studio-context-${user}.json" sed -i -e 's/"description":.*,$/"name": "Compute context to be used for the SAS Studio service by user '${user}'",/g' "/tmp/sas-studio-context-${user}.json" # Use the template to create a new context for this user sas-viya compute contexts create -r -d @/tmp/sas-studio-context-${user}.json > /tmp/new-context-created.json id=$(cat /tmp/new-context-created.json | jq -r '.id') # Grant the user permission to see their new context sas-viya authorization grant --user ${user} --permissions read --reason "${user} can read their own compute context" --object-uri "/compute/contexts/${id}" # Grant the user permission to create sessions under their new context sas-viya authorization grant --user ${user} --permissions create --reason "${user} can create sessions under their own compute context" --object-uri "/compute/contexts/${id}/sessions" done # ls -al /tmp/*context*.json # rm -f /tmp/*context*.json   For demonstration purposes, the example user IDs in user_list in the create_contexts.sh script above includes Henrik (who is in the HR group in my environment, and who we used for our manual example in part 1), plus two users we have not mentioned before: Fiona (who is in Finance ), and Sean (who is in Sales ). Also the user_list intentionally does NOT include a user named Sarah who exists in my environment, and is also in Sales . We will sign into SAS Studio as each of these users later, to show the effect of running the script as below in my environment.   Once you have created it, make the script executable, e.g.:   chmod u+x ~/create_contexts.sh   Check it carefully for errors, and then (in your non-production environment first!), after authenticating against the sas-viya CLI as a member of the SAS Administrators group, run your version of the create_contexts.sh  script.   ~/create_contexts.sh   It outputs quite a bit of JSON to the console (stdout). First is the content of the /tmp/sas-studio-context-template.json file, which should look something like this: { "description": "Compute context to be used by the SAS Studio service", "environment": {}, "launchContext": { "contextId": "d929db8a-dcb0-4220-9c15-86135a432db5", "contextName": "SAS Studio launcher context" }, "launchType": "service", "name": "SAS Studio compute context", "version": 4 } This is followed by two blocks something like the following for each group-specific compute context. Here is the pair of JSON output documents in my results, for the creation of the two authorization rules allowing Finance to read (i.e. see) and create sessions under (i.e. use) their new group-specific compute context: { "acceptItemType": "", "acceptType": "", "contentType": "", "createdBy": "geladm", "creationTimestamp": "2023-12-19T18:07:13.178Z", "description": "", "enabled": true, "id": "b3ba3d8b-541a-47dd-aa69-2b5cd2b5b257", "mediaType": "", "modifiedBy": "geladm", "modifiedTimestamp": "2023-12-19T18:07:13.178Z", "objectUri": "/compute/contexts/437ac37a-c7d4-41ac-9683-ae98f8c2c300", "permissions": [ "read" ], "principal": "Finance", "principalType": "group", "reason": "Finance can read their own compute context", "type": "grant", "version": 10 } The authorization rule has been created. { "acceptItemType": "", "acceptType": "", "contentType": "", "createdBy": "geladm", "creationTimestamp": "2023-12-19T18:07:13.433Z", "description": "", "enabled": true, "id": "2488cb29-e094-4eec-9632-bf803cf9a2f1", "mediaType": "", "modifiedBy": "geladm", "modifiedTimestamp": "2023-12-19T18:07:13.433Z", "objectUri": "/compute/contexts/437ac37a-c7d4-41ac-9683-ae98f8c2c300/sessions", "permissions": [ "create" ], "principal": "Finance", "principalType": "group", "reason": "Finance can create sessions under their own compute context", "type": "grant", "version": 10 } The authorization rule has been created. There should be a similar pair of blocks in the script's output for each other group, and each user.   Results   In my example environment, after manually creating a group-specific compute context for HR in part 1 and then running the script above, let's see what compute contexts are available to our selected users.   Henrik   Henrik should see all of the default compute contexts, plus ones for HR and Henrik:      Compute contexts visible to Henrik - the original default set of contexts, his own, and the one for HR Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page. Fiona   Fiona should see all of the default compute contexts, plus ones for Finance and Fiona:    Compute contexts visible to Fiona - the original default set of contexts, her own, and the one for Finance Sean   Sean should see all of the default compute contexts, plus ones for Sales and Sean:    Compute contexts visible to Sean - the original default set of contexts, his own, and the one for Sales Sarah   Sarah should see all of the default compute contexts, plus one for Sales (we did not create a personal compute context for Sarah):    Compute contexts visible to Sarah - the original default set of contexts, and the one for Sales. We did not create a personal compute context for Sarah. geladm   geladm (a SAS Administrator) should see all of the default compute contexts, plus ones for HR, Sales, Finance, Henrik, Fiona and Sean:   Compute contexts visible to geladm (a SAS Administrator). He can see the original default set of contexts, plus all the other group-specific and user-specific compute contexts. His list of compute contexts is longer than everyone else's, and has a scrollbar as a result.   This shows the script created the contexts we asked it to, they are visible to the users who need to use them, and crucially NOT visible to non-SAS Administrator users who don't need to (and should not be allowed to) use them.   Next steps   Having created all these contexts, the SAS Administrator is now able to customize each of them with, for example: group-specific SAS Workload Orchestrator queues group-specific SAS options (perhaps options which you only wish to set for some groups, and not for all) librefs and macros in the autoexec statement     Yet the list of compute contexts visible in each user's context menu in SAS Studio is not cluttered up with contexts they cannot and should not be able to use.   See you next time! Find more articles from SAS Global Enablement and Learning here. ... View more

Our team is sometimes asked how to create group-specific or user-specific compute contexts in SAS Viya, with permissions set so that users who are not in the group, or are not the user for whom the context was created, don’t see it. There are two aims for the permissions for these contexts: to avoid a user’s compute context menu in SAS Studio being so cluttered up with other users’ compute contexts that they have to look through a long list of contexts to find their own, and to avoid offering users the frustrating experience of being able to select a compute context in SAS Studio or SAS Model Studio which then fails to start. In this post we will see a how to (mostly) manually create a new group-specific compute context, with permissions set up to meet these two aims. We will: Adjust the authorization rules which make all compute contexts visible to all users by default, in e.g. the SAS Studio contexts menu. To do this we will: Disable* the rule that makes all compute contexts visible to all users Run bash commands to make new rules for each out-of-the box compute context so that users can still see them and start sessions under them Create a new compute context for an existing group Create more new rules granting the group permissions to see (and use) their new compute context, while not giving other users or other groups access to it To perform some of these steps, you will need to install the sas-viya CLI and its plugins, configure it with a connection profile and certificates to connect to your SAS Viya cluster, and authenticate the sas-viya CLI as a member of the SAS Administrators custom group. You will also see optional steps which use some of our pyviyatools, to simplify otherwise cumbersome tasks. Next time, in part 2 of this post, we will present another bash script that automates all of the steps above and iterate through lists of groups and users, so you can scale it up and script the creation of a larger number of group- and user-specific contexts.     * SAS Administrators aren’t impacted by disabling the rule that makes all compute contexts visible to all users. There is an out-of-the-box rule which grants SAS Administrators access to all URIs in the system, which means they still see all compute contexts and still be able to create new sessions under each compute context. SAS Administrators will have to scroll through all compute contexts in the dropdown contexts menu in SAS Studio and there is no sensible way to avoid this – except perhaps by not using SAS Studio as a SAS Administrator, or by not opting in to the SAS Administrators assumable group when you sign in to use SAS Studio.   What about batch contexts? It is not possible in the current version of SAS Viya to configure permissions that work they way I'd like them to for group- or user-specific batch contexts, when used from the sas-viya CLI. I will save the topic of a batch context version of this post for another time. It may be that for now, we simply create group- or user-specific batch contexts, but do not attempt to secure them - all users see all batch contexts. It is possible that in future we may get the ability to set permissions for batch contexts that work nicely with the sas-viya CLI and allow us to better manage their visibility.     User-specific or group-specific?     Making group-specific compute contexts is a better idea than making user-specific ones. It is less work to set up, less effort to maintain, and still does the job in most use cases. If users really do need their own user-specific ‘context’, but not their own job queue, it may be sufficient for them to define their own user-specific autoexec code block which runs when their compute session starts, or their own user-specific preamble and post-amble code which runs before each code submission, in SAS Studio – see SAS Studio > User's Guide > Introduction to SAS Studio > Editing the Autoexec file. In this part 1, I will create a group-specific compute context. In part 2, we will include user-specific compute contexts - they are created in much the same way as group-specific ones - no special steps are required.     Starting simple     ‘Out of the box’, SAS Viya has a rule granting Authenticated Users read access to all compute contexts. It’s neat, but it isn’t the best fit for a SAS Viya deployment with dozens of compute contexts, or more. So, we will begin by disabling that rule and adding new rules to make sure all Authenticated Users still have access to the out-of-the-box compute contexts.   We should only do this once, per deployment, and it is easier to do it before we create any user-specific compute contexts, because during the step where we create a new rule granting all Authenticated Users access to read each ‘out of the box’ compute context, we have to distinguish which contexts are ‘out of the box’ from those we created later. Before we create any new ones, that’s easy – all compute contexts that currently exist are 'out-of-the-box'. Later on, obviously you can still make rules for each of them, but it will require manual intervention to choose which contexts you want everyone to be able to see.   In this post, I am going to assume there are no extra compute contexts to begin with, and make a rule for all those that exist, granting all Authenticated Users access to read and create sessions under them, before we create any new compute contexts.   What does the contexts menu in SAS Studio look like for each user, out of the box?   Initially, all users see exactly the same set of compute contexts in SAS Studio. Note that the set of pre-defined contexts seen here depends on which SAS products and solutions are deployed, and on the version of SAS Viya, so do not be surprised if your starting set of contexts differs from the screenshot below. The screenshot below is what I see in one of our GEL workshop environments:    Compute contexts for all users in my environment, 'out-of-the-box'. Here we see them as a SAS Administrator, geladm, but all users see the same set of compute contexts.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Disable and replace rule granting all users read access to all compute contexts     We want to create new contexts without them becoming automatically visible to all users. So, in the Rules page of SAS Environment manager, while logged in as a SAS Administrator, remove (or better, disable) the general authorization rule granting Authenticated Users the Read permission on the URI /compute/contexts/*:    Disable this authorization rule to remove all users' access to see all compute contexts automatically.   It’s easy to search for the rule: type /compute/contexts/* into the search box above the rules table. The rule that matches this pattern and is for the principal Authenticated Users, granting Read permission is the one we want to disable. Right-click the rule, choose Edit, and in the Edit Rule dialog, change the ‘Rule status’ toggle button to ‘off’ (disabled):    Turn the 'Rule status' toggle button off to disable the rule.   Then click Save.   After disabling that rule, members of the SAS Administrators group, like geladm in my environment, are still able to use SAS Studio and get a compute context. They see no difference in behaviour, thanks to the rule that says they get all permissions (to perform all actions) on all URIs – in SAS Viya.   But disabling this rule creates a temporary problem for all non-administrator users. They get an error message when they open SAS Studio, saying “studio-commons-api-icu.client.compute.error.no.contexts.found.msg”:     We need to grant Authenticated Users permission to see, and use, all the out-of-the-box compute contexts again. The rules implementing those permissions will target the individual compute contexts by their IDs. Getting the compute contexts’ IDs is most easily done using the sas-viya compute contexts list command, so next we will do just that.   As a one-time task, from the command line we will list all existing compute contexts, store the results in a file, get the compute context IDs from that file, and iterate through them to create a new authorization rule for each one so to grant all Authenticated Users read access to each existing out-of-the-box context.   As mentioned above, before you can run this, you would need to install sas-viya CLI and its plugins, configure it with a connection profile to your SAS Viya cluster, and authenticate as a member of the SAS Administrators custom group. If you have done that, you can run these commands (adapted as necessary for your deployment)   As a bonus, the following also includes a scripted method of disabling the rule we just disabled above, using the getruleid.py pyviyatool, in case you prefer to do this in a script for your environment. It's no problem to attempt to disable a rule that is already disabled, so you can run it even if you did so already: ####################################################################################### # Important: Do all this once, before creating user- and/or group-specific contexts. # # This fundamentally changes out-of-the-box behaviour that by default, all users see # all compute contexts. After doing this, if you create a new compute context, you # will have to create a new authorization rule granting non-SAS Administrator users # permission to see it, otherwise they won't see it. ####################################################################################### # If you did not do it already... # Disable the rule granting Authenticated Users read access to all compute contexts (/compute/contexts/*) id=$(/opt/pyviyatools/getruleid.py -u /compute/contexts/* -p "authenticatedUsers" | jq -r '.items[0]["id"]') echo ${id} sas-viya authorization disable-rule --id ${id} # If you did this already, it does no harm to run this, and you will see a response saying something like " Rule 07633805-2c76-495a-9f38-a6c6c63eb628 is already disabled.". That is fine. COMPUTE_CONTEXTS_FILE=/tmp/compute_contexts.txt COMPUTE_CONTEXT_ID_FILE=/tmp/compute_context_ids.txt # List the compute context IDs, and store the results (which have a header row) in a text file sas-viya compute contexts list > ${COMPUTE_CONTEXTS_FILE} # Remove the header row tail -n +2 ${COMPUTE_CONTEXTS_FILE} > "${COMPUTE_CONTEXTS_FILE}.tmp" && mv "${COMPUTE_CONTEXTS_FILE}.tmp" ${COMPUTE_CONTEXTS_FILE} cat ${COMPUTE_CONTEXTS_FILE} # Make another file with just the compute context IDs (always the last field, which you can reference as $NF), in each line awk '{print $NF}' ${COMPUTE_CONTEXTS_FILE} > ${COMPUTE_CONTEXT_ID_FILE} cat ${COMPUTE_CONTEXT_ID_FILE} # Add a new authorization rule for each original compute context granting Authenticated Users read access to it while read id; do context="/compute/contexts/${id}" sas-viya authorization grant --authenticated-users --permissions read --reason "Authenticated users can read this original compute context" --object-uri ${context} done <${COMPUTE_CONTEXT_ID_FILE} ####################################################################################### #### End of section you should only run once, before creating user- and/or group-specific contexts. ####################################################################################### After you do this, all other authenticated users can again see (and start compute sessions running under) all the out-of-the-box compute contexts in SAS Studio.     Create a new compute context for a group   Now we can interactively create a new compute context for a group. We will create one manually for the HR group in my environment, based on the default SAS Studio compute context.   In SAS Environment Manager, as a SAS Administrator (geladm in my case), navigate to Contexts and choose the ‘Compute contexts’ view. Then, find the SAS Studio compute context in the list, right-click it, and choose Copy from the popup menu:       In the New Compute Context dialog: Change the name to e.g. “SAS Studio compute context for HR group” Change the description to e.g. “Compute context to be used by HR group for the SAS Studio service” Leave the Launcher context set to “SAS Studio Launcher context”   Under Identity type, click the radio button to select Identities, and at the top right of the identities area below it, click the “Choose identities” button and in the popup, select e.g. “Groups” and then your chosen group e.g. “HR”, and click OK:     The new compute context dialog looks like this just before you click Save:     Click ‘Save’ to save the new compute context for e.g. HR. You should see a brief popup message saying “Created compute context”. You should also see the new compute context appear in the list on the Contexts page in SAS Environment Manager.   Making the new context specific to your chosen group, e.g. HR, creates a new authorization rule for this context, granting members of the HR group permission to create new sessions under the context. Here is the new rule in my environment – note the ‘/sessions’ endpoint after the compute context ID:     However, because of the changes we made a moment ago, although members of HR have permission to create new compute sessions under the new compute context, they still cannot see it in e.g. SAS Studio.   At this point, Henrik’s list of available compute contexts in SAS Studio is the same as it was the last time we looked. Permission to see (Read) the new context has not yet been granted to HR, so we need to do that.   Back in SAS Environment Manager as geladm (my SAS Administrator), find the rule as shown in the screenshot above, granting HR Create permission on /compute/contexts/some-guide/sessions, right-click it, and Copy it. In the Copy Rule dialog, make the following changes: Remove the /sessions suffix from the end of the Object URI. For example the Object URI of the rule I copied was /compute/contexts/26d013e4-0a1e-4f56-9eba-c480714ee53b/sessions, so I deleted the last bit to just leave it as /compute/contexts/26d013e4-0a1e-4f56-9eba-c480714ee53b. Take care to leave the compute context ID intact – don’t accidentally delete any of that, and don't leave the trailing '/'. Leave the Principal Type as ‘Group’ and the Principal as your chosen group (in my case, ‘HR’) Click the ‘Choose’ button to change the Permissions from ‘Create’ to ‘Read’. (Your group only needs Read permission on the new compute context URI, there is no need to leave the ‘Create’ permission selected.) Edit the description to say something like “Users in group HR can see context 26d013e4-0a1e-4f56-9eba-c480714ee53b.” Leave all the other settings as unchanged – several fields are empty, which is fine. Click Save.   Now there should be two rules for HR targeting that compute context, like this:       Having done this, both geladm (a SAS Administrator) and user like Henrik (a member of the HR group) can see the new compute context and can start a compute session under it in SAS Studio. Here is Henrik’s view of the available compute contexts in SAS Studio at this point, showing that he has successfully started a compute session after switching to the new HR compute context:     However, when user Sarah (a member of Sales, and not a member of HR) signs in, she does not see the “SAS Studio compute context for HR group”, she only sees the set of compute contexts she had access to out-of-the-box:     Success!   We have created a new compute context visible and useable to only users in a specific group (plus SAS Administrators). Most importantly, the new context is not visible to (or useable by) users who are not members of that group. It does not clutter up other users’ compute context menu in SAS Studio. However, that was quite a lot of clicking in the web interface, and we have only created one group-specific compute context. That probably felt like a lot of work for a relatively small gain.   In part 2 of this post, we will see an example bash script to automate the creation of many new compute contexts, all secured similarly to be visible to and useable by only members of their intended group or individual users.     ... View more

Someone validating a SAS Viya deployment usually aims to answer some combination of these questions:   Are basic elements of my SAS Viya deployment working? Are the components of my SAS Viya deployment which will be used the most working acceptably well? Do some specific non-functional performance tests of this SAS Viya deployment meet expectations? Are access controls in SAS Viya granting and preventing access to data, content and application functionality in the intended way? There are of course other possible aims for validation beyond these, such as test of integration with data sources or other applications, usability and accessibility tests, tests of internationalization and more. There is no one 'best' way to validate a SAS Viya deployment; a validation procedure should be tailored to a specific deployment, and to answer specific questions relevant to the business' needs. Choosing to include fewer validation tests makes the procedure faster, cheaper and potentially easier to automate. Having more validation steps to a procedure may mean it takes longer and costs more to identify, design, develop and run the tests, but when run they give a more complete view of a deployment's status.   Given all that, this post gives examples of validation steps that we use in the GEL team. It also includes some example tests which I personally don't have any need to run, but which we are sometimes asked about. The examples are not exhaustive; if you have experience of validating SAS Viya deployments and you check for something not mentioned here which you think others should check too, I would love to hear from you.     Edit 02 Oct 2023: In the context of life sciences and pharmaceuticals, Computer System Validation (CSV) is a rigorous testing and documentation process required to satisfy regulators that "the computer systems and their software operate as intended, meet user requirements, and comply with regulatory standards" (to quote Computer System Validation (CSV) in Life Sciences Part 1: Introduction to CSV - Verista). This article does not try to describe such rigorous validation in a regulated industry, and is limited to a more generally applicable set of confirmatory tests which may be useful to any SAS Viya administrator.     SAS Viya Validation Resources   SAS-provided tools documented in SAS Help Center   The SAS Readiness Service checks the status of the SAS Viya platform every 30 seconds, to determine whether it is ready for use. It checks whether SAS endpoints in Kubernetes are responding (e.g. with HTTP 200: OK responses to a REST call), and also whether the SAS Infrastructure Data Server database and OAuth authentication providers are responding. Since it is part of SAS Viya 'out of the box', it offers a universally-available way to check whether SAS Viya is fundamentally operational.   The SAS® Viya® Platform: Deployment Validation section in the SAS Viya Platform Administration documentation in SAS Help Center is a useful resource. It describes how to run the SAS Viya Platform Deployment Report, which is one tool in the SAS Viya 4 Administration Resource Kit, a toolset available in GitHub and which is practically indispensable for many deployment consultants, architects and similar who work with SAS Viya. We use tools in the viya4-ark in most of our GEL workshop collections. Running the script which generates the SAS Viya Platform Deployment Report is both easy and quick.   The SAS Viya Command-line Interface (CLI) is an essential tool for validation, as it is for many other administration activities.     SAS Viya Administration Checklist   The SAS Viya Administration Checklist has a task called Validate your SAS Viya Deployment. It proposes your validation first check whether Kubernetes is fundamentally working and has the expected nodes and namespaces. Then, it suggests some tests to validate SAS Viya, such as application URLs returning a page, SAS Studio code submission working for a trivially simple SAS code statement, presence of loaded data in CAS, some authorization tests and some validation tests of the SAS Programming Run-time which can be done using the SAS Viya CLI.   It also suggests using...   The ValidateViya pyviyatool   ValidateViya is a pyviyatool that runs a series of tests on a Viya environment, validating that it is running as expected. validateviya has a modular design, allowing for the creation of custom tests, the alteration of existing tests, and the removal of unneeded tests. See the vaildateviya User Guide in the pyviyatools project in GitHub.     Basic validation   *Taps microphone* "Is this thing on?"   The aim of basic validation is to run a quick set of tests which will reveal fundamental issues with your deployment fast. We check for things like Kubernetes not working, SAS Viya not being deployed successfully, pods not running, or users being unable to sign in. If major issues prevent a SAS Viya deployment from working at all, you will want to know about it early.   Validate the right one   If you have more than one SAS Viya deployment, a possible pre-requisite is to determine which one to validate. Which hosts, which Kubernetes cluster, which is the URL for the web applications in the deployment to be validated? It is of no use to test the health of the wrong environment, and allow that mistake to give you a false sense of security. Confirm the hostname or IP address for your Kubernetes ingress host and any other hosts you will interact with directly. If you have front-end load balancers, reverse proxies or similar, bypassing these during basic validation will simplify your testing, especially if there is any ambiguity about which deployment will really respond to requests sent to an alias.   Examples of steps in a basic 'is it on?' validation procedure   To give some examples, here are descriptions of some tests in a basic validation procedure for an environment I regularly rebuild - these tests are likely to be valid for nearly any SAS Viya deployment:   Can we make an SSH connection to a node in the Kubernetes cluster (the node we use to run kubectl and other administration tools)? Is kubectl using the correct kube config file for the cluster on which the SAS Viya deployment is running? Do we get the expected number of nodes, and are they all in the expected Ready state, when we run kubectl get nodes? Are the Kubernetes namespaces for SAS Viya, and for supporting applications such as our observability toolset present, in the results of kubectl get ns? How many pods are running in the Viya namespace? Is the number of running within an expected range (e.g. 170-190 pods for the SAS Viya software order I deployed)? How many pods are pending in the Viya namespace? Is the number of pending pods larger than some acceptable minimum? (E.g. from past experience with this environment, I know that there are sometimes 2-3 pending pods out of 180 or so, and this does not necessarily mean there is a problem. But in this environment, more than this number of pending pods usually does indicate a problem.) Is the sas-readiness pod itself reporting as being ready, indicating that its three types of check are all passing? See the SAS Readiness Service for more on this. Can you sign in to SAS Environment Manager as an administrator account? Does the SAS Viya license for this deployment expire on a date sufficiently far into the future? Can you authenticate successfully against the SAS Viya Command-line interface?     Validate frequently-used functional components   If basic validation passes, we generally want to look just a little bit more closely at some applications, to check if the components of SAS Viya that end users will use the most are working. This next stage of validation still needs to be fast, and reveal commonly-occurring issues which might not be revealed by the basic validation tests above.   Examples of steps in a functional validation procedure   Your basic functional validation tests, in your environment, may differ significantly from the following list depending on what your users do most in SAS Viya. The following descriptions are the gist of what is tested, not how I test those things. They would typically be a mix of manual and scriptable tests. For the environment I look after, basic functional validation includes steps like these:   In SAS Environment Manager's Data page, or using the sas-viya CLI's cas plugin, are any CAS tables are loaded into memory, and are they the tables we expect to be loaded into memory in CAS for this environment? Open SAS Studio. Does a compute session under the SAS Studio compute context start successfully? Can we run a trivially simple SAS statement such as proc options; run; , and does it produce normal log output without errors? Can we submit the same program successfully in SAS Batch, using the sas-viya CLI's batch plugin? Does the SAS batch job execute, and return sensible-looking SAS logs with no errors? From SAS Drive, can we open the User Activity report? This is efficient in the sense that it tests several things at once: SAS Drive is working, and we can navigate SAS Viya folders for their contents SAS Visual Analytics is working and able to render charts SAS Cloud Analytic Services (CAS) is working and able to provide data to SAS Visual Analytics The Audit service is running. By default it only loads data into the AUDIT table in CAS once per hour, so we may have to wait for it to run before we see data in the User Activity report. Can a simple predictive model be built, trained, published and validated using tools such as SAS Visual Analytics, SAS Model Studio and SAS Model Manager? A scripted process which passes through key functional steps in these applications should be completed successfully. Can we open and sign in to our chosen log monitoring application (such as OpenSearch Dashboards), and see log messages and their contextual data flowing in from the SAS Viya deployment? Are there an unusual volume of ERROR-level log messages being produced? Can we open and sign in to your metric monitoring application (such as Grafana), and see metric data flowing in from the SAS Viya deployment and its host Kubernetes cluster? Do a few example charts of metrics appear to display normal patterns of metric data, compared to what we would usually expect to see in those charts? If there are any other supporting applications deployed in your Kubernetes cluster alongside your SAS Viya deployment, are they healthy and working?     Validate non-functional performance   Unless something unusual has gone wrong, the same specification of physical and virtual compute and storage resources, with the same versions of Kubernetes and its supporting components running the same release of SAS Viya which has been configured the same way will typically perform about the same every time you deploy it. Non-functional performance validation aims to demonstrate that an environment performs adequately in a series of workload or stability tests, compared either to some benchmark result from a similar environment in the past, or compared to a business objective.   This kind of validation likely to be performed less frequently; it may only need to be done once, or a handful of times, per environment. Therefore, administrators may have less need for this type of validation to be fast or automated. Non-functional testing for processing performance, responsiveness, resilience etc. certainly takes longer to design, and also typically takes longer to perform than basic validation.   This is the aspect of validation I have least need for with the classroom environments I support, so perhaps you would like to reply to this post in the comments below to describe what you need to cover with this type of validation. From my experience of consulting roles in SAS, the following test ideas could be a good starting point:   Can I load a specific-size data set into CAS in an acceptable amount of time? How long does a specific typical program take to run? How long does a data processing job flow take to run? Does it finish successfully within an acceptable time? Can the same data load test be performed at any of the usual times it might need to run, including when the system is under user load, and still complete within an acceptable time? The 'acceptable time' here may be defined by a contract or service level agreement, or may be in comparison with some benchmark result from a previous test. How long does it take a user to sign in and open each of the applications they use most, be that a report, a programming session, a modelling tool etc.? How long does a specific typical report take to open? How long does a specific model flow take to complete? How does responsiveness vary when the system is under high real or simulated end-user workload? (Can this testing be used to define what 'high end-user workload' is, for this environment, and is that enough capacity for the organization who owns it?) Does a backup job complete successfully? Does running a backup have an unacceptable impact on the rest of the system's performance? Does a restore from backup complete successfully? For components of the deployment which are highly available, does the system react in the correct way if I intentionally stop/delete/remove e.g. one pod in the replica set or equivalent. For example. does Kubernetes successfully re-start the failed pod and resume sending traffic to it when it is running again?   I expect I missed some things that people will consider important here. If your SAS environment is subject to a service level agreement (SLA), that should define metrics that can be objectively tested to validate whether the environment meets the SLA or not. So, define performance validation tests that measure those metrics, and can be automated.   Let me know in the comments below what other types of non-functional testing you think a validation procedure should include.     Validate access controls   The Security Policy and Authorization Model tasks in the SAS Viya Administration Checklist describe how access controls should be defined and documented for a SAS Viya deployment. Follow these to an extent that is proportionate in the context of how tightly or loosely your SAS Viya environment and the data it contains need to be protected from unauthorized access.   Then, again as appropriate for the degree of rigor required, you can define a series of validation tests to perform once, occasionally or regularly to prove that users who should have access to data, content and application functionality do have that access, and that users who should not, do not.   You may find some value in tools to help you automate this. pyviyatools that might help include:   explainaccess.py - a flexible tool that can explain access controls on a SAS Viya folder, report, or for another object or a service URI, for any specific user or group, or for all users and groups who have applicable access controls getruleid.py - pass in a SAS Viya object or service URI, and a user or group, and get back the ID of a SAS Viya general authorization rule that applies to that object for that user listcaslibsandeffectiveaccess.py - for a specific caslib, or for all caslibs on all CAS servers, return a list of all effective access controls in the CAS authorization system listcastablesandeffectiveaccess.py - a somewhat flexible variation of the above for CAS tables: return a list of all effective access on all CAS tables (or a specific table) in all CAS libraries (or a specific CAS library) on all servers. Can optionally include row-level permissions and permissions on source tables. listgroupsandmembers.py - return list of all groups and all their members, optionally including their email addresses (if available in the identity service's data) listrules.py - list either all general authorization rules (typically for further processing) or rules that target a specific URI and/or mention a specific user or group testfolderaccess.py - assert whether a folder is accessible to a user or not. This tool is intended to be called with a specific folder path, principal, permission and a sense (whether access with this permission is expected to be granted or not). It will respond 'TEST PASSED' or 'TEST FAILED' with the specifics of what was tested. We run a series of tests using this tool in one of our GEL workshops, to validate folder permissions for a set of folders for a set of users and groups, and show how one folder is 'incorrectly' protected (intentionally so) and causes one test in the suite to fail. As an aside, the simpler and more regular your authorization model design is, the more easily validated it will be. If validating access controls is important in your organization, time spent in carefully designing and documenting the authorization model so that it is easily understood, clearly described and simple will be much more cost-effective to the business than a haphazardly designed and carelessly implemented authorization model. It will also be far easier to validate.   Between the four general types of validation tests described above, you should be able to get a good sense of whether a SAS Viya deployment is working, useable for the purpose it was intended to be used for, performant and correctly secured. There are certainly other kinds of validation that could be performed, but I think those are the main and most common ones. But what do you think - did I miss a kind of test that everyone ought to include when they validate SAS Viya? Let me know in the comments below.     Find more articles from SAS Global Enablement and Learning here. ... View more

In this Part 2 of a two-part series, we will install and use the pyviyatools on Windows.   The pyviyatools require the SAS Viya CLI and the trusted certificates file it requires, and of course Python - preferably python3. In this guide I chose to install pyviyatools using git from a command line, though like most of the things featured in this guide, there are other ways to get it. If you followed Part 1 of this guide, Install and use the SAS Viya CLI on Windows, much of the hard work is already done.   If you have not already read and followed Part 1, I would suggest you glance at this guide to get an idea of what it covers, and then go and follow the steps in Part 1 first.   This guide documents the concluding part of one possible ‘happy path’ for setting the SAS Viya CLI and pyviyatools up on Windows from scratch. If you have some of the components already, you may find you can skip the corresponding section. But between Part 1 of this guide and the steps below, below you can find the complete process.   Contents   In Part 2 of this guide, we will cover: Dependencies Install pyviyatools and the packages it requires Python3 Upgrade pip Python3 requests module Python3 configobj module git pyviyatools Use pyviyatools from a Windows command prompt Create a .authinfo file Authenticate using loginviauthinfo.py and your .authinfo file pyviyatools Examples   No doubt this guide could be improved. If you see areas you think are overcomplicated, wrong or unnecessary, or if you have questions about why I chose a particular command or installation method, I would love to hear from you. Leave a comment below or get in touch!   Dependencies   In this Part 2, we assume all the components from Part 1 are already present, so we only need to install the things in the 'Part 2' box in the dependency diagram. We will assume that everything outside that box (the Windows client machine, chocolatey, the SAS Viya CLI and the trustedcerts.pem certificates file which the pyviyatools also requires) are already set up and validated:  Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Install pyviyatools and the packages it requires Before proceeding with these steps, ensure you have followed the steps in Part 1 of this guide, and that the SAS Viya CLI is working from a Windows Command Prompt on your Windows machine, that it is connected to your SAS Viya deployment, and that you can authenticate successfully with a SAS Viya username and password and can run SAS Viya CLI commands successfully. To set up pyviyatools and the things it requires, we return to using PowerShell.   Python3 There are many ways to install Python on a Windows machine, and any of them should be okay if you can run python --version , from both PowerShell and Windows Command Prompt and get a Python 3.x.x version number in response. For the sake of consistency, we will install it using chocolatey here. Open a new PowerShell terminal window, and see if Python3 is already installed: python --version If Python3 is installed, you should see something like this, and you can continue to the next section, to upgrade pip: Python 3.11.4 If Python3 is not installed, you should see something like this (in red): python3 : The term 'python3' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + python3 --version + ~~~~~~~ + CategoryInfo : ObjectNotFound: (python3:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException If Python3 is not installed, run this command to install Python3 using chocolatey, which takes a few minutes: choco install python3 -y After installing python, close the PowerShell terminal, and open a new one. Then, run python --version again to verify that Python3 is installed and in your path. You should see something like this: Python 3.11.4 Upgrade pip   From a PowerShell terminal, run this to upgrade the Python package manager, pip: python.exe -m pip install --upgrade pip   Python3 requests module   From a PowerShell terminal, run this to install the Python3 requests module, a rich set of tools for making HTTP requests, e.g. for calling REST APIs like those exposed by SAS Viya: python -m pip install requests   Python3 configobj module   From a PowerShell terminal, run this to install the Python3 configobj module, a config file reader and writer: python -m pip install configobj   git Install git if it is not already installed. Git can be installed many ways; any method is probably fine so long as you end up getting a response similar to that shown below when you run git version . Since we are using chocolatey to install other packages in these instructions, we may as well pick that method for this step. See whether git is already installed. In the PowerShell terminal window, run this: git version If you see something like this, git is already installed: git version 2.41.0.windows.1 If you see something like this, git is not installed: git : The term 'git' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1 + git + ~~~ + CategoryInfo : ObjectNotFound: (git:String) [], CommandNotFoundException If git is not already installed, run this to install it: choco install git.install -y After installing git, close the PowerShell terminal, and open a new one. Then, run git version again to verify that git is installed and in your path. You should see something like this: git version 2.41.0.windows.1 pyviyatools We are finally ready to deploy pyviyatools. Clone the pyviyatools project from GitHub into C:\ViyaHome, using git. pyviyatools is a public project, so you do not need to authenticate to GitHub. Run this from the PowerShell terminal: Push-Location Set-Location Env: cd C:\ViyaHome git clone https://github.com/sassoftware/pyviyatools.git Pop-Location Verify that the pyviyatools project was cloned to C:\ViyaHome\pyviyatools: dir C:\ViyaHome\pyviyatools Partial expected output (with some files omitted): PS C:\Users\student> dir C:\ViyaHome\pyviyatools Directory: C:\ViyaHome\pyviyatools Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 7/14/2023 6:24 AM templates -a---- 7/14/2023 6:24 AM 57 .gitattributes -a---- 7/14/2023 6:24 AM 153 .gitignore -a---- 7/14/2023 6:24 AM 70 application.properties -a---- 7/14/2023 6:24 AM 6521 applyauthmodel.py -a---- 7/14/2023 6:24 AM 4857 applyfolderauthorization.py -a---- 7/14/2023 6:24 AM 4308 applyviyarules.py -a---- 7/14/2023 6:24 AM 7899 archivefiles.py -a---- 7/14/2023 6:24 AM 3656 callrestapi.py ... Some files omitted ... -a---- 7/14/2023 6:24 AM 3987 toggleviyarules.py -a---- 7/14/2023 6:24 AM 5327 unittestsadm33.sh -a---- 7/14/2023 6:24 AM 8687 unittestsadm34.sh -a---- 7/14/2023 6:24 AM 4563 unittestviya4.sh -a---- 7/14/2023 6:24 AM 3150 updatedomain.py -a---- 7/14/2023 6:24 AM 4731 updatepreferences.py -a---- 7/14/2023 6:24 AM 7843 validateviya-manual.md -a---- 7/14/2023 6:24 AM 23618 validateviya.py PS C:\Users\student> Run the pyviyatools setup.py script. This tool uses the Python3 configobj module we installed earlier to set values in a pyviyatools configuration file called application.properties . In the PowerShell terminal window, run this, substituting the location where you installed the sas-viya CLI executable for C:\ViyaHome\CLI , if it is somewhere else on your Windows machine. Recall that we installed and configured the SAS Viya CLI in Part 1 of this guide. cd C:\ViyaHome\pyviyatools ./setup.py --clilocation C:\ViyaHome\CLI --cliexecutable sas-viya Expected output: Note: updating C:\ViyaHome\pyviyatools\application.properties NOTE: configuration values set to {'sascli.location': 'C:\\ViyaHome\\CLI', 'sascli.executable': 'sas-viya'} Optional: If you want to be able to run pyviyatools without specifying the path, add the pyviyatools directory to your path. In the PowerShell terminal window, run this: [Environment]::SetEnvironmentVariable("Path",[Environment]::GetEnvironmentVariable("Path", [EnvironmentVariableTarget]::Machine) + ";C:\ViyaHome\pyviyatools", [EnvironmentVariableTarget]::Machine) Close the PowerShell terminal window, and open a new one, to pick up the change to the machine’s path environment variable. Use pyviyatools from a Windows command prompt   Create a .authinfo file   Create a .authinfo file. In the following command, I have used the username and password of a SAS Viya administrator account: user geladm , password lnxsas . Substitute the username and password of the account you wish to use by default for these values in the command below. In the PowerShell terminal window, run this $authinfo_file=$HOME+'\.authinfo' [IO.File]::WriteAllLines($authinfo_file, 'default user geladm password lnxsas') type $authinfo_file Note: We use WriteAllLines here to write the line to the .authinfo file, because when I used echo , the character encoding ended up being UTF-16, which was not understood by python3’s configObj module.   Authenticate using loginviauthinfo.py and your .authinfo file I have not had success getting this working from a PowerShell prompt yet, so here we switch to a Windows command prompt. Open a new Windows Command Prompt window, to pick up any changes we made to your path environment variable. In the command prompt, run this. (If you did not add the pyviyatools path to your path environment variable, you will need to specify the full path to loginviauthinfo.py and any other pyviyatools you run, e.g. C:\ViyaHome\pyviyatools\loginviauthinfo.py 😞 set current_namespace=gelcorp set SAS_CLI_PROFILE=%current_namespace% set SSL_CERT_FILE=%USERPROFILE%\.certs\%current_namespace%_trustedcerts.pem set REQUESTS_CA_BUNDLE=%SSL_CERT_FILE% loginviauthinfo.py Expected result (showing your profile name instead of ‘ gelcorp ’, your ingress host instead of ‘ gelcorp.rext03-0175.race.sas.com ’ and your SAS Viya user – ideally an administrator – instead of ‘ geladm ’): C:\Users\student>loginviauthinfo.py Logging in with profile: gelcorp Getting Credentials for: gelcorp.rext03-0175.race.sas.com Logging in as user: geladm Enter credentials for https://gelcorp.rext03-0175.race.sas.com: Login succeeded. Token saved. C:\Users\student> Pyviyatools Examples The results of each of the following examples is from one of the GEL workshop environments. Obviously the caslibs, members of SAS Administrators group, folder ids, launcher context details and so on will vary between SAS Viya deployments. List caslibs in your default CAS server   In the command prompt, run this (prefixed with C:\ViyaHome\pyviyatools\ or the path you to your copy of the pyviyatools, if you did not add the pyviyatools directory to your path): listcaslibs.py Expected output (caslibs shown depend on the caslibs visible to your authenticated user in your SAS Viya deployment – caslibs visible to my administrative user, geladm , in my SAS Viya deployment are shown in the output below): C:\Users\student>listcaslibs.py server,caslib cas-shared-default,CASUSER(geladm) cas-shared-default,Financial Data cas-shared-default,Formats cas-shared-default,hrdl cas-shared-default,ModelPerformanceData cas-shared-default,Models cas-shared-default,Public cas-shared-default,salesdl cas-shared-default,Samples cas-shared-default,SystemData C:\Users\student> List members of the SAS Administrators group   In the command prompt, run this: listgroupsandmembers.py --id SASAdministrators Expected output: groupid,groupname,grouptype,groupproviderid,memberid,membername,membertype,memberproviderid SASAdministrators,SAS Administrators,group,local,geladm,"geladm",user,ldap SASAdministrators,SAS Administrators,group,local,GELCorpSystemAdmins,"GELCorp System Admins",group,ldap Get the folderid of the /Public folder   In the command prompt, run this: getfolderid.py --f /Public Expected output: creationTimeStamp ,createdBy ,modifiedTimeStamp ,modifiedBy ,version ,id ,name ,description ,type ,memberCount ,properties , "2023-07-13T08:08:51.478982Z","anonymous","2023-07-13T08:08:51.478982Z","anonymous","1","fef7a224-d3fd-4c03-8a51-fdd05b0cbfe0","Public","Public folder for general access.","folder","0","{'allowMove': 'false', 'uuid': '935842da-9ba0-479c-99e3-6a4e489322fc'}", Compare this output with that from the sas-viya folders show command: sas-viya --output text folders show --path /Public Explain the access controls on the /Public folder   In the command prompt, run this: explainaccess.py -f /Public --header Expected output: principal,read,update,delete,secure,add,remove,read(convey),update(convey),delete(convey),secure(convey),add(convey),remove(convey) authenticatedUsers,grant*,prohibit,prohibit,prohibit,grant*,grant*,grant*,grant*,grant*,prohibit,grant*,grant* SASAdministrators,grant,grant,grant,grant,grant,grant,grant,grant,grant,prohibit,grant,grant Validate your SAS Viya platform is working   In the command prompt, run this: validateviya.py Expected output: Data Collection Test Started: Logged in User Data Collection Test Started: List Users Data Collection Test Started: List Base Folders Data Collection Test Started: List CAS Servers Data Collection Test Started: List CAS Server Metrics Data Collection Test Started: List CAS Server Caslibs Data Collection Test Started: List CASLib Tables Computation Test Started: Run Test SAS Code name ,id "geladm","geladm" name ,id "SAS LDAP Service Account","sasldap" "SAS System Account","sas" "CAS System Account","cas" "SAS Administrator","sasadm" "SAS Test User 1","sastest1" "SAS Test User 2","sastest2" "geladm","geladm" "Douglas","Douglas" "Delilah","Delilah" "Alex","Alex" "Amanda","Amanda" "Ahmed","Ahmed" "Fay","Fay" "Fernanda","Fernanda" "Fiona","Fiona" "Frank","Frank" "Fred","Fred" "Hamish","Hamish" "Hazel","Hazel" "Heather","Heather" "Helena","Helena" "Henrik","Henrik" "Hugh","Hugh" "Santiago","Santiago" "Sarah","Sarah" "Sasha","Sasha" "Sean","Sean" "Sebastian","Sebastian" "Shannon","Shannon" "Sheldon","Sheldon" "Sophia","Sophia" "hrservice","hrservice" "salesservice","salesservice" "financeservice","financeservice" name ,description "Users","Base Folder for all user folders." "Public","Public folder for general access." "Products","Products folder for samples, canned objects and other SAS-provided content." "gelcontent","Base folder" "Conversational Flows","Conversational Flows Folder" "Model Repositories","None" name ,host ,port ,description "cas-shared-default","sas-cas-server-default-client","5570","controller" serverName ,systemNodes ,systemCores ,cpuSystemTime ,memory "cas-shared-default","4","32","0.013651","1319040" name ,scope ,description "CASUSER(geladm)","global","Personal File System Caslib" "Financial Data","global","gelcontent finance" "Formats","global","Stores user defined formats." "hrdl","global","gelcontent hrdl" "ModelPerformanceData","global","Stores performance data output for the Model Management service." "Models","global","Stores models created by Visual Analytics for use in other analytics or SAS Studio." "Public","global","Shared and writeable caslib, accessible to all users." "salesdl","global","gelcontent salesdl" "Samples","global","Stores sample data, supplied by SAS." "SystemData","global","Stores application generated data, used for general reporting." serverName ,caslibName ,name "cas-shared-default","systemData","AUDIT" "cas-shared-default","systemData","AUDIT_ACTIVITIES" "cas-shared-default","systemData","AUDIT_ACTIVITIES_PROPERTIES" "cas-shared-default","systemData","AUDIT_ACTIVITIES_URIS" "cas-shared-default","systemData","SASVIYATYPES" runSuccessful ,jobState "True","completed" From here on, you should be able to run sas-viya commands and run any of the pyviyatools as permitted by the versions of the software you have available, and the permissions of the user you defined in your .authinfo file. The SAS Viya CLI has an extensive set of plugins, documented in SAS Help Center here: https://go.documentation.sas.com/doc/en/sasadmincdc/default/calcli/n1vth8mtb8ipprn1prz5j26p3nvc.htm.   pyviyatools provides many convenient tools/scripts which my GEL colleague Gerry Nelson and I, and a number of other contributors have written to enable or simplify certain tasks in SAS Viya. It is documented in markdown files in the pyviyatools project in GitHub, particularly in: README.md: https://github.com/sassoftware/pyviyatools/blob/master/README.md INSTALL.md: https://github.com/sassoftware/pyviyatools/blob/master/INSTALL.md loginviauthinfo.md describes how to use loginviauthinfo.py, one of our most useful tools, to authenticate to SAS Viya before running either pyviyatools or SAS Viya CLI commands: https://github.com/sassoftware/pyviyatools/blob/master/loginviauthinfo.md EXAMPLES.md: https://github.com/sassoftware/pyviyatools/blob/master/EXAMPLES.md SUPPORT.md: https://github.com/sassoftware/pyviyatools/blob/master/SUPPORT.md CONTRIBUTING.md: https://github.com/sassoftware/pyviyatools/blob/master/CONTRIBUTING.md All the tools I have tried in the course of writing this guide worked well on Windows, as they are supposed to. However, due to the nature of our work, my fellow pyviyatools developers and I use them in LINUX more than in Windows. The tools are supposed to work the same on both but it is possible that you may find a tool that does not work as well on Windows as it does in LINUX. Please let us know about any issues that you come across while using the pyviyatools, by raising an issue in the pyviyatools project or by emailing one of us. It would help if you mention that you are using it in Windows, if you are. My thanks to Gerry Nelson and Allan Tham for their help in discussing and refining some of the things I included in this guide, and to Gerry in particular for his work in developing and publishing the pyviyatools.   See you next time!   Find more articles from SAS Global Enablement and Learning here. ... View more

In this Part 1 of a two-part series, we will go through a beginning-to-end process to install, configure and use the SAS Viya Command-Line interface on Windows. In Part 2, we will install and use the pyviyatools on Windows, which will be a little simpler, once we have done the hard work of completing Part 1.   Why do we need guides like this? Is it not all documented already? Well, yes... but...   In the SAS Global Enablement and Learning team, we (and people attending our workshops) normally install and use both the SAS Viya CLI and pyviyatools on Linux machines. Even if we want to run these tools from our own Windows laptop or desktop, we generally find it convenient to do so from a Bash shell running in Windows Subsystem for Linux. If this is an option for you, it is really nice. Installation of these tools in Linux is comparatively straightforward, and seems much easier to script than it is on Windows.   However, customers whose end users have Windows machines often want to install the SAS Viya CLI and pyviyatools on those Windows machines. Both tool sets do run on Windows, but beginning-to-end instructions for how to set up all the various components and dependencies are hard to find. It seems you have to piece them together from documentation in several different places, which is tedious.   This guide is therefore one possible ‘happy path’ for setting these tools up on Windows from scratch. There are a LOT of steps, which may be part of the reason why there are few other guides to the whole procedure. If you have some of the components already, you may find you can skip the corresponding section. But below you can find the complete process. I hope it turns out to be useful.   Contents   In Part 1 of this guide, we will cover: Dependencies Prerequisites Windows Client Machine PowerShell and Windows Command Prompt are both required Installation directories Install the SAS Viya CLI Installing the SAS Viya CLI is difficult to automate Download SAS Viya CLI using a web browser Install SAS Viya CLI and its plugins Enable SAS Viya CLI to communicate with SAS Viya Chocolatey curl kubectl kubeconfig file Certificates file Define SAS Viya CLI profiles Validate that sas-viya CLI can access your SAS Viya deployment Use the SAS Viya CLI from a Windows command prompt SAS Viya CLI Examples No doubt this guide could be improved. If you see areas you think are overcomplicated, wrong or unnecessary, or if you have questions about why I chose a particular command or installation method, I would love to hear from you. Leave a comment below or get in touch!   Dependencies   The following diagram shows how the packages required to use the SAS Viya CLI and pyviyatools depend on each other, for installation and at run time, and how some of them depend on prerequisites.   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   The green boxes are things that we will install if they are not already installed. Really, all the things in green boxes require a Windows client machine, but showing that would not make the diagram any more clear.   The SAS Viya CLI has been carefully designed not to have much in the way of dependencies. However, if you have enabled Transport Layer Security for your SAS Viya platform, the Windows machine where the SAS Viya CLI runs must trust the certificates presented by the SAS Viya server in order to communicate with it. This is achieved by providing it with a bundle of trusted CA certificates, shown as ‘certificates file’ in the diagram. SAS Help Center's Command-Line Interface: Preliminary Instructions explain this in more detail. They also explain how to obtain that file using kubectl and a kubeconfig file, steps which are a part of this guide.   Since our goal is to install both the SAS Viya CLI and pyviyatools, we may as well use kubectl (a pre-requisite of pyviyatools) to get the necessary certificate file ourselves, rather than just having you provide it as a prerequisite.   Your Windows machine may already have some of these tools installed. If you find you already have a component like python3 or git, or you prefer to install it some other way, that is fine. You may need to adapt some of the installation instructions below to adapt for differences between your machine and the more-or-less new Windows VM I used to write the instructions.   Prerequisites   Pre-requisites are shown as grey boxes in the dependency diagram. This article does not cover how to create: A SAS Viya deployment, in a Kubernetes cluster. Your Kubernetes administrator, SAS Administrator, deployment consultant or service provider sets this up. A kubeconfig file is required to deploy SAS Viya. You could use this kubeconfig file, or another one that your Kubernetes administrator provides, whichever they prefer. When SAS Viya is deployed, a trustedcerts.pem certificates file is created automatically as part of that process, and is stored by the SAS Logon service. No additional steps are required to create this, and we will get a copy of it during the process described in this guide. A username and password that allow you to authenticate to your SAS Viya deployment, preferably as a SAS Administrator. Get this from your SAS Administrator. A Windows client machine on which you can install the chocolatey package manager, curl, kubectl and the sas-viya CLI, and if you continue to part2 (coming soon), python3 and its requests and configobj modules, git and finally pyviyatools. Windows Client Machine   You will need a Windows machine to try installing SAS Viya CLI and pyviyatools. Use your own Windows desktop/laptop if you like and have sufficient permissions.     PowerShell and Windows Command Prompt are both required   I have chosen to use both PowerShell and Windows Command Prompt for this guide, since each is required for certain tasks.   PowerShell has better commands (cmdlets) for things like setting environment variables and unzipping .zip archives, and it is likely the shell a modern Windows administrator will be more familiar with. However, I have not yet discovered how to (or if you can) run the sas-viya CLI in PowerShell.   I found fewer examples showing how to install packages we need using Windows Command Prompt, so it would take more work to convert these instructions to run solely in a Command Prompt, though I think you could. The SAS Viya CLI and pyviyatools both work in a Command Prompt, and I think it is arguably more familiar to non-Windows administrators.   I would love to hear from you if: you know how to get the SAS Viya CLI working in PowerShell (or if you know for sure that you can’t) you can convert all steps in this guide to work in Windows Command Prompt without too much additional complexity   Installation directories   These instructions put kubectl, a kubeconfig file, the sas-viya CLI executable, and pyviyatools in the following directories: Tool or file Directory Kubectl C:\Program Files\kubectl Kubeconfig file $HOME\.kube\config SAS Viya certificates $HOME\.certs SAS Viya CLI executable C:\ViyaHome\CLI pyviyatools C:\ViyaHome\pyviyatools But none of them have to be in those directories. You are free to put any of these things in a different directory, as required by your Windows machine’s disk space or permission constraints, or to suit your preferences. Modify references to the path for each component in e.g. environment variables accordingly.   Install the SAS Viya CLI   In this Part 1 of the guide, we will install the SAS Viya CLI, but also install chocolatey, curl and kubectl, and provide a kubeconfig file so that we can get the certificates file that the SAS Viya CLI needs to trust TLS certificates presented by SAS Viya. If your goal is to set up the SAS Viya CLI only, and not pyviyatools, you can stop at the end of part 1.   Other readers may want to continue on to part 2, to install pyviyatools on Windows. Since pyviyatools depends on the SAS Viya CLI, and because in part 2. I chose to use the chocolatey package manager to install python and git, you should complete part 1 of this guide first even if your main aim is to install pyviyatools.   Preliminary set-up instructions for the SAS Viya CLI can be found in the SAS Help Center documentation at: https://go.documentation.sas.com/doc/en/sasadmincdc/default/calcli/n1e2dehluji7jon1gk69yggc6i28.htm   Installing the SAS Viya CLI is difficult to automate   Unless you have a tool that can navigate to a web page in a browser and click a button in that web page automatically, you cannot fully automate installation of the SAS Viya CLI. Such tools are commonly used to functionally test web pages (among other things), but most of us don’t have one, and it doesn’t make sense to spend the money or effort setting one up just to script this one step.   Without such a tool, you must either: click a button on a web page popup dialog in your browser, in order to accept the ‘SAS License Agreement for Download’, or download the SAS Viya CLI executable ahead of time, and provide it e.g. in a volume accessible to scripts which you can run on your Windows client machine. We prefer option '2' above for our workshop environments. For these instructions, option '1' above is simpler.     Download SAS Viya CLI using a web browser   In a web browser in your Windows client machine, search the web for "SAS Viya CLI download" or browse to https://support.sas.com/downloads/package.htm?pid=2512. I used Chrome on my machine, but any browser should work fine. Sign in to sas.com. In the web page that opens once you have signed in, find the download link for ‘sas-viya for Windows’:   At the time of writing this was sas-viya-cli-1.21.10-windows.zip, but this is updated quite regularly; you should choose the current version. Click the link to download the .zip file.   Read the ‘SAS License Agreement for Download’ and click the ‘Accept’ button if you accept it:   Note: This step cannot currently be automated without software which I think is too expensive or complex to recommend for this use case alone.   Since I used Chrome as my browser, the .zip file was automatically downloaded to $HOME\Downloads (aliased as %USERPROFILE%\Downloads if you are using Windows Command Prompt). Other browsers may place the .zip file in another location by default. If they do not save it to your Downloads directory by default, Save As, move or copy it there yourself.   Install SAS Viya CLI and its plugins   Open a new PowerShell terminal window. It may be convenient to pin it to the Windows Task Bar or Start Menu. In your PowerShell terminal window, and run this to create a directory to contain the extracted SAS Viya CLI executable, unzip the downloaded file to $HOME\Downloads\sas-viya-cli, and to then copy the sas-viya.exe executable to C:\ViyaHome\CLI: mkdir C:\ViyaHome\CLI $files = Get-ChildItem $HOME\Downloads\sas-viya-cli*.zip | select-object -first 1 foreach($f in $files){Expand-Archive $f -DestinationPath C:\ViyaHome\CLI} Get-ChildItem C:\ViyaHome\CLI Tip: Scroll the textbox above to the right if necessary.   Run this to install the sas-viya CLI plugins – they are automatically installed to a new directory, at $HOME\.sas: cd C:\ViyaHome\CLI .\sas-viya plugins install --repo SAS all Add the sas-viya CLI directory path to your machine’s Path environment variable. In the PowerShell terminal window, run this: [Environment]::SetEnvironmentVariable("Path",[Environment]::GetEnvironmentVariable("Path", [EnvironmentVariableTarget]::Machine) + ";C:\ViyaHome\CLI", [EnvironmentVariableTarget]::Machine) Tip: Scroll the textbox above to the right if necessary, to see the whole command.   Close the PowerShell terminal window. We will open a new one in the next step, to pick up the change to the machine’s path environment variable.   Enable SAS Viya CLI to communicate with SAS Viya   We will need to provide a certificates file and set some environment variables before we can use the SAS Viya CLI to connect to our SAS Viya deployment. To get the certificates file, we will set up kubectl and provide a kubeconfig file (see Prerequisites  above) for the Kubernetes cluster where the SAS Viya platform is running. This set of steps is performed in PowerShell.   Chocolatey   Chocolatey is an open-source command-line package manager for Windows. We will use it to install packages in both Part 1 and part 2 of this guide.   The following instructions are based on Chocolatey Software Docs | Setup / Install (https://docs.chocolatey.org/en-us/choco/setup). With the Windows VM I used to develop these instructions, the first attempt at installation results in an error message asking you to restart the machine, and the second attempt at installation succeeds. Open a new Windows PowerShell terminal window. Run this command: Get-ExecutionPolicy If the response is Unrestricted , continue to next step. If the response is Restricted , then run one of these commands: Set-ExecutionPolicy AllSigned or Set-ExecutionPolicy Bypass -Scope Process Run this to install Chocolatey. Installation takes several minutes, and at one stage there will be no new console output for several (5-10) minutes: Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1')) Tip: Scroll the textbox above to the right if necessary, to see the whole command. If the previous command finishes by showing the message below (in red – but don’t panic, it’s okay!), do what the message says and reboot your Windows machine: .NET Framework 4.8 was installed, but a reboot is required. Please reboot the system and try to install/upgrade Chocolatey again. At C:\Users\student\AppData\Local\Temp\2\chocolatey\chocoInstall\tools\chocolateysetup.psm1:815 char:11 + throw ".NET Framework 4.8 was installed, but a reboot is re ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OperationStopped: (.NET Framework ...ocolatey again.:String) [], RuntimeException + FullyQualifiedErrorId : .NET Framework 4.8 was installed, but a reboot is required. Please reboot the system and try to install/upgrade Chocolatey again. Once your Windows machine has restarted, sign in again, and open a PowerShell terminal window again. Re-run the command above to try installing Chocolatey again. This time it should complete in a few seconds, and be successful:   curl   Run this command in the same PowerShell window to install curl: choco install curl -y kubectl See Install and Set Up kubectl on Windows | Kubernetes for the latest instructions. Create a directory for the kubectl executable. It does not have to be in C:\Program Files\kubectl, but that path seems logical to me. In the PowerShell terminal window, run this: mkdir "C:\Program Files\kubectl" Install kubectl. In the PowerShell terminal window, run this. You should cd to the directory you created in the previous step. And this curl command fetches the current version of kubectl (1.27.2) at the time I wrote this guide. See Install and Set Up kubectl on Windows | Kubernetes for the latest version, as new versions are released frequently. You may need to find the version of Kubernetes your cluster is running, and use a compatible version of kubectl. cd "C:\Program Files\kubectl" curl.exe -LO https://dl.k8s.io/release/v1.27.2/bin/windows/amd64/kubectl.exe Validate kubectl. In the PowerShell terminal window, run this: & "C:\Program Files\kubectl\kubectl.exe" version --client --output=yaml Expected output, showing the version of kubectl you just installed: PS C:\Program Files\kubectl> & "C:\Program Files\kubectl\kubectl.exe" version --client --output=yaml clientVersion: buildDate: "2023-05-17T14:20:07Z" compiler: gc gitCommit: 7f6f68fdabc4df88cfea2dcf9a19b2b830f1e647 gitTreeState: clean gitVersion: v1.27.2 goVersion: go1.20.4 major: "1" minor: "27" platform: windows/amd64 kustomizeVersion: v5.0.1 PS C:\Program Files\kubectl> Add the kubectl directory path to your machine’s Path environment variable. In the PowerShell terminal window, run this, if necessary substituting the full path to the directory where you installed kubectl for C:\Program Files\kubectl if you installed it somewhere else: [Environment]::SetEnvironmentVariable("Path",[Environment]::GetEnvironmentVariable("Path", [EnvironmentVariableTarget]::Machine) + ";C:\Program Files\kubectl", [EnvironmentVariableTarget]::Machine) Tip: Scroll the textbox above to the right if necessary, to see the whole command. Close the PowerShell terminal window and open a new one, to pick up the change to the machine’s path environment variable. Test that kubectl is now in your path. Run this from any directory in the PowerShell command window (it should also work from a Windows command prompt): kubectl version --client --output=yaml Expected output, showing the version of kubectl you just installed: PS C:\Users\student> kubectl version --client --output=yaml clientVersion: buildDate: "2023-05-17T14:20:07Z" compiler: gc gitCommit: 7f6f68fdabc4df88cfea2dcf9a19b2b830f1e647 gitTreeState: clean gitVersion: v1.27.2 goVersion: go1.20.4 major: "1" minor: "27" platform: windows/amd64 kustomizeVersion: v5.0.1 PS C:\Users\student> kubeconfig file   Create a directory for the kubeconfig file. In the PowerShell terminal window, run this: mkdir $HOME\.kube Copy your kubeconfig file (see Prerequisites above) to the file path and filename $HOME\.kube\config . Make sure the file does not have a filename extension such as .txt . The kubeconfig file should be named simply config . Tips:   Get a kubeconfig file from the Kubernetes cluster administrator who maintains the Kubernetes cluster that SAS Viya is deployed into. If you want to give it another name, or put it in another directory, you can define an environment variable called KUBECONFIG and give it the value of the path to the kubeconfig file you want to use, and then kubectl will use that config file. This is useful if you have more than one kubeconfig file and wish to switch between them. You can specify a kubeconfig file on the kubectl command line ( kubectl --kubeconfig path ), but if becomes a bit cumbersome and clutters up the command, so I prefer not to do that. Run this from the PowerShell terminal prompt to view the contents of the kubeconfig ( config ) file to verify it is in the expected location: type $HOME\.kube\config Here is a screenshot showing the content of a config file (with the certificate data obscured). Yours should resemble this, though the server, cluster, user and context names will differ:       Validate that you now have access to your Kubernetes cluster using kubectl and your kubeconfig file. Run this from any directory in the PowerShell command window (it should also work from a Windows command prompt): kubectl get ns Expected output is a list of the namespaces in your Kubernetes cluster, e.g. here in PowerShell, but the output is almost identical from a command prompt. We will switch to using a command prompt later, when we use the sas-viya CLI: PS C:\Users\student> kubectl get ns NAME STATUS AGE argo Active 10d cert-manager Active 10d default Active 10d gelcorp Active 10d kube-node-lease Active 10d kube-public Active 10d kube-system Active 10d nfs Active 10d nginx Active 10d v4mlog Active 10d v4mmon Active 10d PS C:\Users\student> One of the Kubernetes namespaces should be the namespace where SAS Viya is deployed – in the example above, that namespace is gelcorp .   Note: It is useful to be able to connect to more than one SAS Viya deployment. So, I prefer to include the namespace name in any configuration variables or file names which refer to that SAS Viya deployment. Therefore, from here on in this guide, wherever you see the string gelcorp in a variable or file name, you should substitute the name of your SAS Viya namespace into that variable or filename, instead of gelcorp .   Certificates file   In this step, we copy a trustedcerts.pem certificates file from the SAS Logon service in your SAS Viya deployment to allow the SAS Viya CLI to trust the TLS certificates that SAS Viya will present to it. If you have not enabled TLS for communication between your SAS Viya deployment and external clients (browsers and the CLI), and you access SAS Viya using http, not https, you may be able to skip this step. Create a directory for the certificates. In the PowerShell terminal window, run this: mkdir $HOME\.certs Optional: See the name of your SAS Viya deployment's sas-logon-app pod. Remember to replace gelcorp in the command which follows with the name of your SAS Viya deployment’s namespace. In the PowerShell terminal window, run this: kubectl -n gelcorp get pod -l 'app=sas-logon-app' Store the sas-logon-app pod name in a variable: $SAS_LOGON_APP_POD_NAME=$(kubectl -n gelcorp get pod -l 'app=sas-logon-app' | select-string sas-logon-app | Foreach-Object { $_.ToString() -split '\s+'} | select-object -first 1) echo $SAS_LOGON_APP_POD_NAME Copy the trustedcerts.pem file from the sas-logon-app container in the sas-logon-app pod to a file named gelcorp_trustedcerts.pem in the .certs directory you just created. Run this in PowerShell, substituting all occurrences of gelcorp for your namespace name: Push-Location Set-Location Env: cd $HOME kubectl -n gelcorp cp $SAS_LOGON_APP_POD_NAME":security/trustedcerts.pem" .certs\gelcorp_trustedcerts.pem -c sas-logon-app Pop-Location Note: The code above can surely be improved. I had trouble concatenating the destination path $HOME\.certs\gelcorp_trustedcerts.pem in the command, so I had to change directory instead, and for neatness change back afterwards. Let me know if you see a neater way to do that! Verify you got the certs file, again substituting gelcorp for your namespace name: type $HOME\.certs\gelcorp_trustedcerts.pem Expected results – LOTS of output!     Define SAS Viya CLI profiles   Optional: see details of the ingress defined for your Viya deployment’s sas-logon-app service. Remember to replace gelcorp in the command which follows with the name of your SAS Viya deployment’s namespace. In the PowerShell terminal window, run this: kubectl -n gelcorp get ing | findstr sas-logon-app Expected output is something resembling this, showing in this example that the ingress hostname is gelcorp.pdcesx03038.race.sas.com : PS C:\Users\student> kubectl -n gelcorp get ing | findstr sas-logon-app sas-logon-app nginx gelcorp.pdcesx03038.race.sas.com,*.gelcorp.pdcesx03038.race.sas.com 10.43.17.23 80, 443 10d Get the ingress URL and store it in a shell variable. In the PowerShell terminal window, run this – you might need to modify it to fit the string returned from kubectl get ing on your environment, and again, remember to replace both occurrences of gelcorp in the command which follows with the name of your SAS Viya deployment’s namespace: $INGRESS_URL=$(kubectl -n gelcorp get ing | select-string sas-logon-app | Foreach-Object { $_.ToString() -split '\s+'} | select-string gelcorp |%{$_ -split ','} | select-object -first 1) echo $INGRESS_URL In your PowerShell terminal window, create a default sas-viya CLI profile which will be used if you don't specify which profile to use when calling the sas-viya executable, and one for your SAS Viya namespace, e.g. mine is called gelcorp , but you should name yours for your SAS Viya namespace. Specify http or https as appropriate for the endpoint: sas-viya.exe --profile Default profile set-endpoint https://$INGRESS_URL sas-viya.exe --profile Default profile toggle-color off sas-viya.exe --profile Default profile set-output fulljson sas-viya.exe --profile gelcorp profile set-endpoint https://$INGRESS_URL sas-viya.exe --profile gelcorp profile toggle-color off sas-viya.exe --profile gelcorp profile set-output fulljson Validate that sas-viya CLI can access your SAS Viya deployment   Now you have everything you need to access a SAS Viya deployment using the SAS Viya CLI. Let’s validate that we can, using the Windows Command Prompt.   Note: This step uses Windows Command Prompt, not PowerShell! Open a Windows Command Prompt terminal window. It may be convenient to pin it to the Windows Task Bar or Start Menu. In your Windows Command Prompt set environment variables for using the sas-viya CLI. As before, substitute the name of your SAS Viya deployment's namespace for gelcorp : set current_namespace=gelcorp set SAS_CLI_PROFILE=%current_namespace% set SSL_CERT_FILE=%USERPROFILE%\.certs\%current_namespace%_trustedcerts.pem set REQUESTS_CA_BUNDLE=%SSL_CERT_FILE% Run this (from any directory) in your Windows Command Prompt to log in to your SAS Viya deployment from the SAS Viya CLI. Provide the username and password of the account you will use to login to SAS Viya (see Prerequisites above), in place of username geladm password lnxsas in the example below: sas-viya auth login -u geladm -p lnxsas Expected output is something like this: C:\Users\student>sas-viya auth login -u geladm -p lnxsas Enter credentials for https://gelcorp.pdcesx03038.race.sas.com: Login succeeded. Token saved. C:\Users\student> You should now be able to run sas-viya commands to do anything that username is authorized to do. Try using the SAS Viya CLI to get information about the SAS Administrators group: sas-viya identities list-groups --id SASAdministrators Expected output is something like this (with some lines omitted): C:\Users\student>sas-viya identities list-groups --id SASAdministrators { "items": [ { "creationTimeStamp": "2023-07-13T08:15:30.881Z", "description": "Provides assumable access throughout the general authorization system.", "id": "SASAdministrators", "links": [ --- some lines omitted--- ], "modifiedTimeStamp": "2023-07-13T08:15:30.881Z", "name": "SAS Administrators", "providerId": "local", "state": "active", "type": "group", "version": 1 } ] } If you see JSON output similar to that above, your SAS Viya CLI has successfully authenticated and run a command against your SAS Viya deployment. Let’s try a few more examples.   Use the SAS Viya CLI from a Windows command prompt   Note: This step uses Windows Command Prompt, not PowerShell!   SAS Viya CLI Examples   There are lots of other videos and blog posts describing use of the sas-viya CLI. A search here, or using your favorite web search engine will produce many results, and I'd encourage you to explore topics, tasks and plugins that seem interesting to you. It is a fantastic set of tools! But here, I'll pick some examples that seem interesting to me - and I hope to you.   The results of each of the following examples is from one of the GEL workshop environments. Obviously the values returned will vary between SAS Viya deployments, so expect your results to differ from mine, and go explore what you can do!   See the usage help text for the sas-viya compute contexts command All sas-viya plug-ins, including the compute plug-in are designed to be self-documenting. Add a -h at the end of any partial command to see what sub-commands, command options and arguments it can take. This is a great way to discover what they can do. In the command prompt, run this to see usage for the sas-viya compute contexts command: sas-viya compute contexts -h Expected output (other versions of the plugin may offer different options and arguments to these): NAME: sas-compute-cli contexts - Manages the compute contexts. USAGE: sas-compute-cli contexts command [command options] [arguments...] VERSION: 1.37.8 COMMANDS: create Creates a compute context. delete, del Deletes a compute context by name, ID, or ordinal. generate-template, gen Generates a template to create a compute context. help, h Shows a list of commands or help for one command. list Lists the compute contexts' names and IDs. show Shows a compute context by name, ID, or ordinal. show-template, show-t Shows a template that is used to create a compute context. validate, val Validates the compute context session. OPTIONS: --help, -h Shows help. List compute contexts In the command prompt, run this to list compute contexts currently defined in your SAS Viya deployment (and that your current user is authorized to see): sas-viya compute contexts list Expected output (your compute contexts may differ to these, and the IDs will be different): 1. SAS Studio compute context c4eeed2e-2c5e-48ee-ac69-9c82889a4081 2. SAS Job Execution compute context 14f5cc90-bd7c-4306-bee2-830cd6c34bee 3. CAS Formats service compute context 4c786325-25d0-46e6-81d7-038d3bc9efa7 4. CAS Management service compute context 989ba5c6-2ede-4011-90e2-d69110aa2d6d 5. SAS Model Manager compute context d731a2dd-249b-4301-9296-31ef8364049e 6. Import 9 service compute context 695b9e48-c0cf-4be5-bd4b-be1e8d3c5cb4 7. Natural Language Conversations service compute context f23a7bc4-78b4-48a8-bfab-f6ee184edc97 8. Data Mining compute context f3ec8041-bf8b-46a0-9805-2ab9c1f50a76 9. SAS Backup job compute context e436717f-cd5c-43fe-9231-c2d805692b62 List the details of the SAS Studio Compute Context In the command prompt, run this to view details of the SAS Studio Compute Context. You can indicate which compute context you want to see by ordinal number, name or id - here I chose to identify it by name: sas-viya compute contexts show --name "SAS Studio compute context" Expected output (some lines omitted for brevity): { "createdBy": "sas.studio", "creationTimeStamp": "2023-07-13T08:18:09.70045Z", "description": "Compute context to be used by the SAS Studio service", "environment": {}, "id": "c4eeed2e-2c5e-48ee-ac69-9c82889a4081", "launchContext": { "contextName": "SAS Studio launcher context" }, "launchType": "service", "links": [ --- some lines omitted --- ], "modifiedBy": "sas.studio", "modifiedTimeStamp": "2023-07-13T08:18:09.70045Z", "name": "SAS Studio compute context", "version": 4 } If your objective was only to set up the SAS Viya CLI, and not pyviyatools, you are finished, and I hope this process has been useful.   No doubt this guide could be improved. If you see areas you think are overcomplicated, wrong or unnecessary, or if you have questions about why I chose a particular command or installation method, I would love to hear from you. Please leave a comment below or get in touch.   If you want to continue to set up pyviyatools, look no further than part 2 Install and use the pyviyatools on Windows.    My thanks to my colleagues Gerry Nelson and Allan Tham for their help in discussing and refining some of the things I included in this guide.   See you next time!   Find more articles from SAS Global Enablement and Learning here. ... View more

In this post I would like to highlight a neat way to set a useful bit of SAS Viya Programming Run-time Environment configuration from the command-line, and in the process remind you that pre-started (and reusable) compute servers are a good thing for SAS administrators to know about.   SAS Viya's Programming Run-time Environment has the ability to pre-start a pool of available compute servers. The idea is that when users request a compute session in a specific compute context in e.g. SAS Model Studio or SAS Studio, the compute session starts in a few seconds rather than a few tens of seconds because the compute session runs in a compute server that is already started. The user doesn't need to wait for the SAS Compute Service to ask SAS Launcher Service to launch a new Compute Server pod, wait for the pod to start up, and wait for all the containers in it to initialize. Those things still have to happen, but they happen before the user requests their compute session.   The apparent improvement in session start time is especially noticeable when you run something like a model pipeline which starts several compute sessions in quick succession.   The necessary steps to create a compute context which pre-starts compute servers are documented in: Configure Compute Servers to Run under a Shared Account Configure Reusable Compute Servers Configure a Pool of Available Compute Servers However, if you like to script things so that e.g. your environment creation can be automated, read on. We're going to look at a way to enable a pool of pre-started compute servers with just three commands. Plus, the method we'll use can easily be modified to create other compute contexts with attributes and restricted access.   We have covered pre-started compute servers before. 18 months ago my GEL colleague Rob Collum wrote here about improving concurrency performance in SAS Viya. One of the things he covered was how to create a pool of reusable compute servers, and he showed how to do it using the SAS Environment Manager's web interface. And 14 months ago I used the settings we'll review today as examples in my post Add, update and remove compute context attributes with new pyviyatools. But it is a while since we've written about pre-started compute servers here, so perhaps they are worth mentioning again.   First, let's refresh our memories with a few reminders about pre-started compute contexts: A compute context you configure to have pre-started available compute servers must run those compute servers under a shared service account You must store credentials for that shared service account in advance using the compute service's plugin to the sas-viya CLI If you are running a version of SAS Viya earlier than version 2023.03 (Stable or LTS), then as Rob mentioned in his post, you cannot do this if your users identities are provided to SAS Viya by SCIM, you can only do this if they are provided by LDAP. However, once you have upgraded to SAS Viya version 2023.03 (stable or LTS) or later, deployments using SCIM can now also use shared service accounts to run sessions for SAS Compute Server (and other things). Only compute servers can be pre-started, you cannot pre-start batch or connect servers Each pre-started compute server pod consumes a bit of CPU and memory on the host nodes in your Kubernetes compute node pool, even when it is idle. Not only that, even when those pods are idle and not actually using much CPU and memory, Kubernetes effectively reserves an amount of CPU and memory for their use as specified by their container's CPU and memory 'requests' values. Having pre-started compute servers may result in Kubernetes being unable to run as many - or any - new pods on the nodes where those compute servers run, if doing so would overcommit the total CPU or memory available to Kubernetes for running pods on the node beyond the total cumulative amount of CPU or memory requested by all the containers in all the pods currently running on the node. So pre-starting compute pods effectively reserves a chunk of your total compute (or other pod-running) capacity, whether it is being used or not. TL;DR: The presence of pre-started compute server pods may prevent new compute pods from being started, even when those pre-started compute pods are idle. But with all that taken into consideration, if your users need to run a model pipeline - i.e. a series of model steps - in SAS Model Manager, or start SAS programs in Studio, and much quicker session startup time is worth the tradeoff of running the compute session as a shared account, then creating a pool of pre-started available compute servers might be for you!   Here's how.   Step 1: Store a credential for a shared service account   You must store a credential for a shared service account whether your identities are provided by LDAP or SCIM. However, I have only had a chance to try it with LDAP so far, so the steps below are specific to shared service accounts provided by LDAP. Consult Stuart's post for how to do the equivalent when your identities are provided by SCIM.   If you are using password authentication, and your users are provided by an LDAP provider such as Microsoft Active Directory (AD) or Azure Active Directory Services (AADS), read on.   First, authenticate to the sas-viya CLI as an administrator using e.g. sas-viya auth logon, or the pyviyatool loginviauthinfo.py (described in loginviauthinfo.md).   Then optionally, run this to list existing compute credentials:   sas-viya compute credentials list   If you have not created any compute credentials yet, the response will be:   There are no shared service account credentials.   Then run this to save a compute credential for a service account called modelservice , who has password mySecretPassword123 . Obviously, substitute the username and password of the service account your pre-started compute servers should actually run as for these example values:   sas-viya compute credentials create -u modelservice -p mySecretPassword123 -d "Shared service account called modelservice" The expected response is something like:   2023/06/07 12:34:56 The shared service account credential for modelservice was created successfully.   If you like, confirm it was created by listing compute credentials again:   sas-viya compute credentials list   If the credential was created successfully, the response will be something like:   Shared Service Account Credentials: 1. modelservice - compute-password - Shared service account called modelservice   Step  2: Create JSON file that defines the new compute context   The file below is based on the example in SAS Viya Platform Administration > Servers and Services > Programming Run-Time Environment > Programming Run-Time Servers > SAS Compute Server and Compute Service > CLI Examples. Save it somewhere which I will refer to as /path/to/file/prestarted_reusable_modelservice_cc.json .   { "name": "Data Mining compute context as modelservice", "description": "A compute context for the SAS Visual Data Mining and Machine Learning application as modelservice.", "attributes": { "runServerAs": "modelservice", "reuseServerProcesses": "true", "serverMinAvailable": "1" }, "launchContext": { "contextName": "Data Mining launcher context" }, "launchType": "service", "authorizedGroups": [ "Modellers" ] }   Adapt the JSON compute context template to your needs:   Change /path/to/file/prestarted_reusable_modelservice_cc.json to whatever file path and file name you wish to contain your JSON compute context definition Set our preferred name and description for this new compute context Provide the name of the service account you created in place of modelservice in the runServerAs attribute Optionally, you may wish to add further attributes: One that is quite useful is "serverInactiveTimeout": "900" . From the documentation reference in the next bullet: "Is used only when the reuseServerProcesses attribute is set. The value is the time in seconds that an inactive server remains running before being terminated. An inactive server is defined as a server without an active compute session.". When idle, you will see the pre-started compute servers terminate at the end of such an inactive period - and new ones are restarted if this brings the total of compute servers in the context below the number specified by serverMinAvailable . The Server Contexts section in SAS Help Center has a list of compute server attributes Set the value of the serverMinAvailable attribute to the initial number of compute servers you wish to have pre-started. See note below. Choose the most appropriate launcher context for the value of the contextName attribute: For SAS Model Studio use, leave it set to "Data Mining launcher context" For SAS Studio use, change it to "SAS Studio launcher context" Either change the group name in the authorizedGroups section from Modellers  to the groupID of the group you want to have access to this compute context, or if you do not want to restrict access to this compute context, remove the authorizedGroups section - and the comma at the end of  "launchType": "service" - to make this compute context available to all authenticated users.   Note: Remember that pre-started compute servers will consume some resources on your Kubernetes cluster's compute nodes, and as explained above will also reserve resources for potential use, so that they cannot be used for running other pods. The optimal serverMinAvailable number for the workload your users are running is something you may need to find by trial-and-error. I have seen a use case of a small environment with a couple of users who ran relatively small model pipelines, where 4 was a good value for serverMinAvailable . I have also seen another use case of a large shared classroom server used for teaching classes of students how to design models in SAS Model Studio, where 25 was was the chosen value for serverMinAvailable . This was the use case Rob used for the example values in his post. It is a value that you should tune, over time and with experience of what works best for your organization's workload.   Save your changes to /path/to/file/prestarted_reusable_modelservice_cc.json .   Step 3: Create the new compute context with pre-started compute servers   To create the new compute context, use the sas-viya command-line interface, still authenticated as an administrator, to run this command:   sas-viya compute contexts create -r -d @/path/to/file/prestarted_reusable_modelservice_cc.json   Note: the @ symbol in front of the file path is correct and required. You can of course create - and update, and delete - a new compute context interactively in SAS Environment Manager. My aim in this post is to show how to do it from the command line.   Step 4: See if compute servers have been pre-started   If you have access to a visual interface which shows pods running in your SAS Viya namespace in your cluster, you should see the number of sas-compute pods increase. However, depending on the interface, it may be difficult to distinguish the sas-compute pods started under this compute context (and running as the modelservice account) from other compute pods.   If you have access to the kubectl command-line interface for Kubernetes and a kube config file that lets you access your SAS Viya deployment's cluster, this command can show sas-compute pods launched specifically by the SAS Compute service (as opposed to by a user in SAS Model Studio or SAS Studio), and running as the modelservice account:   kubectl get pod -l launcher.sas.com/requested-by-client=sas.compute,launcher.sas.com/username=modelservice   Tip: Scroll the textbox above to the right if necessary, to see how the username who requested the pod is specified as a filter to kubectl get pods.   Here are some example results, when my new compute context's serverMinAvailable value was set to "1" , and I had no other SAS Compute sessions running in this compute context or as modelservice :   NAME READY STATUS RESTARTS AGE sas-compute-server-b91b1b9f-8827-4b57-9535-160cbf6e2cc4-t8mgl 1/1 Running 0 25s   Possible reasons you might not see the new compute servers starting up include:   You need to wait a little longer - a minute or two is usually enough The credentials for the service account are incorrect - try deleting and re-creating it There is not currently enough available CPU or memory to start new pods on Kubernetes nodes in your compute node pool - you may see fewer compute servers starting than you requested The account you specified in the runServerAs attribute is already running the maximum number of launched SAS Programming Run-time Environment sessions allowed, as set by the SAS_LAUNCHER_USER_PROCESS_LIMIT setting. See my blog post: Limit a user’s simultaneous compute server processes in Viya 2021.1 and later for more on this.   Assuming you did see the new sas-compute server pods starting up, you can now see if they improve performance of your model pipelines.   Use the new compute context in SAS Model Studio   Sign in to SAS Model Studio. If you limited access to the new compute context to only members of a specific group,  sign in to SAS Model Studio as a user who is in that group.   Then, create or open a model pipeline. To change the compute context used to run each step of this model pipeline, click the 'Settings' icon, in the top right corner of the project tab.   In the Project Settings dialog, choose Compute Context, and switch from the default 'Data Mining compute context' to your new compute context which pre-starts compute servers:   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   I do not believe it is possible to configure individual steps in a model pipeline run under different compute contexts. The whole pipeline runs under the same compute context.   In the screenshot above, you can just about see a four-step sequential pipeline, created from a gradient boosting model in SAS Visual Analytics. When this project runs, each step runs in its own separate compute context. Some models run multiple steps at the same time. You should notice a significant improvement in the total 'wall clock' time (as compared to CPU time) when running these models while sufficient pre-started compute servers in the chosen compute context are available and not currently in use.   Use the new compute context in SAS Studio   SAS Studio users are generally familiar with switching compute contexts - click on the compute context icon top-right in SAS Studio to change to a different context:     If you select a compute context which has unused (i.e. available) pre-started compute servers, you should see a very noticeable improvement in how quickly your compute session in SAS Studio is ready to run SAS code.   The tradeoff for this is that the compute session runs as the shared service account, and not as you (or rather, as the signed-in user). This may have some impact on your filesystem permissions, if you access anything on the filesystem, such as base or other path-based libraries, filerefs etc. But the tradeoff may be worth it for the much faster compute session startup time.   So now you know how to script configuration of the compute context from the command line, and can see how easily it could be automated as part of an environment configuration script. Hopefully, that's useful to someone out there.   Thank you to Rob Collum for reviewing this post and for his great comments. Any remaining errors or omissions are mine.   See you next time!     Find more articles from SAS Global Enablement and Learning here. ... View more

I'm delighted to announce our new SAS Viya Administration Checklist is available now on GitHub:   https://github.com/sassoftware/viya4-admin-checklist   This checklist has 67 administration tasks for SAS Viya 2020.1 and later, organized into initial and regular task lists. There is a suggested frequency for the regular tasks. You, as an IT administrator or a SAS administrator, should consider performing the tasks in these lists for the SAS Viya 2020.1 and later environments that you maintain. Perform all tasks that are relevant to your environment to keep your SAS Viya deployment operating at its best over the long term.     This new checklist has been in development for a long time. The GEL Administration team and a select group of technical experts across the company have all worked on creating it, and we're so happy to make it available in this first release. But it is a living project, and we will add to it over time. If you see something you can improve, reach out to me or any of my GEL admin team colleagues, or raise a an issue in the GitHub project and let us know what you'd like to see changed, added or fixed. You can even contribute your own tasks. We have previously published similar checklists as PDF documents for earlier versions of SAS: Checklist of SAS Viya 3 Administration Tasks: https://support.sas.com/resources/papers/checklist-sas-viya-administration-tasks.pdf Checklist of SAS 9 Administration Tasks: https://support.sas.com/resources/papers/Platform-Administration-Tasks.pdf   Let me know what you think!   Acknowledgements   THANK YOU to all my SAS colleagues who contributed their suggestions and thoughts over the past several months. Not every suggestion made it into this release. We still have all the ideas that didn’t make this first cut, and will use those suggestions – and new ones – to drive future updates to the project. It will grow!   A particular thank you to my GEL Administration team colleagues: @ScottMcCauley, @GerryNelson ,  @AjmalFarzam and @GillesChrzaszcz who all wrote up tasks for this checklist. See you next time! ... View more

Someone contacted SAS Support recently asking for help with an issue in their SAS Viya platform running on Kubernetes. Support asked the customer to upload some logs from the relevant SAS Viya job to the support track. But this customer didn't have a way to get those logs. The job in question had ended, and the customer had no log (or metric) monitoring solution deployed or configured which had stored its log messages. The logs were gone.   This customer had no good way to access to their logs, except for the kubectl logs command which, in the case of transient pods like those which run compute jobs, is really only useful for pods that are still running. It's unlikely to be helpful for pods which have finished. So, basically, until this customer deploys some kind of log monitoring solution, and while they are at it a metric monitoring solution too, it will be near impossible for Support to help them troubleshoot that issue.   This is not the ideal first experience when you have just deployed the current SAS Viya platform. Please, if you are a SAS Administrator you need both a log monitoring solution and a metric monitoring solution for your SAS Viya platform.     Why do you need a log and metric monitoring solution for the SAS Viya platform?   In A first look at logging in SAS Viya 4 | Global Enablement & Learning Blog back in May 2020, I explained that the way SAS Viya [platform] log messages are collected and made available to SAS administrators is very different from the way they were handled in SAS Viya 3 or SAS 9. In correctly designed Kubernetes applications, the app should not attempt to write to or manage log files. Instead, log messages are simply written to an output stream: stdout and stderr . Kubernetes picks up this output and stores it in pod logs.   Rudimentary log viewing tools such as kubectl logs or a cloud service provider's Kubernetes web interface (which more or less offers the same functionality as kubectl logs in a web app) are good enough for simple use by e.g. a Kubernetes administrator and deployment consultants. But they don't offer long-term storage, aggregation over many pods, searching or much other functionality. In any case the SAS Administrators may not have access to them.   This means you need a log monitoring solution to capture SAS Viya log messages. The solution should store the log messages and their contextual information, and let you to chart, filter and search them.   While we're at it, you also need a metric monitoring solution, which will similarly capture and store metrics from your Kubernetes cluster and from your SAS Viya platform, store them, and let you chart, filter and explore them.   Plan to include both log and metric monitoring as part of your deployment. Add or enable both as soon as you can reasonably do so if you don't already have them! You may also want to ensure you have an alerting and at least a basic auditing capability. Collectively all these things fall under the category of observability tools.     Which log and metric monitoring tools should you use?   There are several choices. None is terribly expensive, or very difficult to deploy or use, but some are definitely better than the others.   Our top recommendation for observing SAS Viya deployments is SAS Viya Monitoring for Kubernetes. It consists of a log monitoring stack, and a metric monitoring stack, and a set of samples. It is documented in SAS Help Center, and is open source, supported by SAS, regularly updated by SAS developers and available license free on GitHub. It runs and is supported on all the Kubernetes and Cloud Service providers that SAS Viya is supported on.   If you are willing to do a bit more work or sacrifice a bit of convenience and data richness for the sake of consistency with the observability tool a customer already uses for other Kubernetes applications, all the major cloud service providers offer their own observability tools: Microsoft Azure and AKS has Azure Monitor, comprised of Azure Monitor Metrics and Azure Monitor Logs. Amazon AWS and EKS has Amazon CloudWatch, with Amazon CloudWatch Metrics and Amazon CloudWatch Logs. Google Cloud Platform and GKE has Google Operations Suite, with Cloud Logging and Cloud Monitoring. OpenShift OCP has the OpenShift Container Platform Monitoring Stack.   The SAS Viya Monitoring for Kubernetes project even has samples for how to configure each to work with SAS Viya.   If you are using Upstream Open Source Kubernetes to deploy SAS Viya (one of our newest options), you'd probably choose to create your hosting infrastructure and Kubernetes environment using SAS Viya 4 Infrastructure as Code (IaC) for Open Source Kubernetes, which works with SAS Viya 4 Deployment project on GitHub. This in turn can deploy SAS Viya Monitoring for Kubernetes with its cluster-monitoring and viya-monitoring tasks.   If you already have Kubernetes and/or already have another observability solution with log and metric monitoring support, you could use that.   Just be aware that if you choose something other than SAS Viya Monitoring for Kubernetes, some work is going to be involved to get the same richness of information from SAS Viya platform logs and metrics that is available in SAS Viya Monitoring for Kubernetes, and to keep it up-to-date over time as you update to new versions Kubernetes and the SAS Viya platform.   But please, do set up log and metric monitoring. It's essential.   Further reading Learn more by reading my first look at logging in SAS Viya 4.   To see more recent versions of SAS Viya Monitoring for Kubernetes in action, watch: SAS Demo | Viewing Logs with SAS Viya Monitoring for Kubernetes: Changing Log Levels - YouTube. ...and its supporting SAS Communities post: Code for YouTube video: "Viewing Logs with SAS Viya Monitoring for Kubernetes: Changing Log Levels SAS Demo | Viewing Logs with SAS Viya Monitoring for Kubernetes: Managing Log Retention - YouTube Look for other posts on observability, logging and monitoring (or log monitoring and metric monitoring) here, including: Four Tips for Exporting logs from OpenSearch Dashboards’ Generate CSV function Managing logging data retention period and size in SAS Viya Monitoring for Kubernetes Managing monitoring data retention period and size in SAS Viya Monitoring for Kubernetes Tips for upgrading SAS Viya Monitoring for Kubernetes 1.1.8 to version 1.2.0 Log monitoring updates in the SAS Viya Monitoring for Kubernetes project Overview of updates to the SAS Viya Monitoring for Kubernetes project Exporting logs from SAS Viya on Kubernetes – a survey of five available methods Managing access to logs for specific Viya deployments with Kibana A second look at Azure Monitor Logs for AKS clusters A first look at Azure Monitor Logs for AKS clusters   Find more articles from SAS Global Enablement and Learning here. ... View more