2022.1.0 Release Notes

source $env(VOVDIR)/tcl/vtcl/vovflexlmdlib.tcl
package require vovurlutils

global HEALTHLIB_PRODUCT_MAP HEALTH_PROCS env

set HEALTHLIB_PRODUCT_MAP(doTestHealthMyFeature) "nc"
# registerHealthCheck doTestHealthMyFeature -checkfreq 10 -forceCheckfreq -mailfreq 10 -forceMailfreq
lappend HEALTH_PROCS(list) doTestHealthMyFeature

proc doTestHealthMyFeature { args } {
    global HEALTH_PROCS
    set homeUrl $HEALTH_PROCS(homeURL)
    # VovMessage "now running doTestHealthMyFeature"
    set subject "TestMyHealthFeature"
    set body "\nHi,\n\nWe ran TestMyHealthFeature.\n"
    doMailNotify doTestHealthMyFeature "@ADMIN" $subject $body
}

TIMEVAR doTestHealthMyFeature {
    Tue {
        suppressMail doTestHealthMyFeature 1
    }
    06:00-08:00 {
        suppressMail ALL 0
        suppressMail doTestHealthMyFeature 0
    }
    default {
        suppressMail ALL 1
        suppressMail doTestHealthMyFeature 1
    }
} 

1. CONFIG(target) - specify the space separated list of cluster(s)/execution host(s), jobs will be submitted using bsub -m option.

   CONFIG(targetName,env) - specify a different named environment per cluster/execution host.

   LSFtarget/LSFTarget - specify cluster/execution host per job in the resource string regardless of the CONFIG(target).

2. CONFIG(cluster) - specify the space-separated list of the cluster(s), jobs will be submitted using bsub -clusters option

   CONFIG(clusterName,env) - specify a different named environment per cluster.

   LSFcluster/LSFCluster - specify cluster per job in the resource string regardless of the CONFIG(cluster).

TIME:STATE:SIGNAL,includerx,excluderx,skiptop 
VovPreemptMethod can now take the form: 
VovPreemptMethod resource SIGNAL -signal SIGNAME -include patternList -exclude patternList 

nc preempt can now take the form: 
nc preempt -method TIME:STATE:SIGNAL,includerx,excluderx,skiptop 

If you reference NC_STOP_SIGNALS, the EXT format is : EXT:SIGNAL:INCLUDERX:EXCLUDERX:SKIPTOP

You can now use :SIGNAL:INCLUDERX:EXCLUDERX:SKIPTOP to do the same thing but without vovjobctrl getting invoked. Job control will be handled directly by the tasker. This also works with VOV_STOP_SIGNALS.

You must set nowrapper=True for a job to be run with no wrapper. When stopping a job via the REST API via a "PUT" request with action='stop', the API now accepts an additional field named "skiptop". If False, the specified stop signal may also be sent to the top job. Normally the top job the is vw wrapper.

When preempting a job via the REST API with a "PUT" request with action='preempt', the API now accepts a syntax for the method field of: TIME:STATE:SIGNAL,includerx,excluderx,skiptop.

This is similar to the updated preemption plan format.

-multiphase [1|0] -mpres "resource string" -multiphase 1 enables multiphase jobs.

-mpres sets the resources that will be used for each phase.

The '%' is used as a delimeter for the resources of each phase. e.g. -mpres "linux64 foo%linux64 bar:linux64 baz" By specifying the resources of each phase and designating that certain resources are only allocated to certain taskers, one can run different phases of a job on different taskers.

vtk_resourcemap_set License:blue UNLIMITED License:blue_tasker1 
vtk_resourcemap_set License:red UNLIMITED License:red_tasker2 
vtk_resourcemap_set License:blue_tasker1 1 tasker1 
vtk_resourcemap_set License:red_tasker2 1 tasker2

nc run -multiphase 1 -mpres "linux64 
License:blue%linux64 License:red%linux64 License:blue" -- -e BASE -D /home/jjmcwill/testDir/testMultistage.sh 

MPRESOURCES: Contains the same resources passed in -mpres, and is used to reset the job resources for each phase.

MPCURRENTPHASE: Contains an integer indicating the current job phase. It starts at one, and has a max value of 9.

What the job script sees: The running job script will see an environment variable named VOV_JOB_PHASE which is set to the current phase. The script writer will need to use that to decide what work to do for that phase. If the script exits with an exit code of 216, Accelerator will increment the job phase, change the job resources, and reschedule the job to run again. If the script exits with an exit code of 0, the job is considered "Done", and MPCURRENTPHASE is reset to 1.

Failed jobs: If a job fails during a phase with a code other than 0 or 216, it is considered FAILED and MPCURRENTPHASE will not increment. If the job is invalided and re-run (e.g. nc rerun -f JOBID), the job will re-run starting at MPCURRENTPHASE and further phases will run if the job exits with code 216, as described above.

Logging: After the first phase is run, subsequent phases of the job will have the command rewritten so that the wrappers are passed "-a -A", telling the wrappers to append to the job log. This is so that all phases of the job get their stdout and stderr logged to the same file. If this was not done, each phase of the job would overwrite the log, and the user would only see the output from the last phase that was run. If Accelerator does not detect one of the standard vov wrappers at the beginning of the command line, it will assume the command is not using a wrapper. In this case, it will look for the standard ">;" redirect symbol in the command and replace it with ">>;".

REST Support: In the payload for submitting a job via rest, two new fields are allowed: multiphase and mpres. Setting multiphase = True enables multiphase job support. Setting the mpres field behaves the same as described for the command line argument described above. Re-running a multiphase job that has failed via the REST re-run API will behave similarly to rerunning a failed multiphase job from the command line as described above.

This has been changed so that the queueName also contains a status of whether or not vovwxd sees the status of the basequeue as ONLINE or DOWN.

The new format of EXTLINKS is: "queueName1:status=STAT1 URL1 queueName2:status=STAT2 URL2 ..."

When visiting the web UI for the wx project, the link for a base queue that is down will be shown in red instead of the customary gray.

BUCKETINFO(AUXRESOURCES)

BUCKETINFO(BUCKETID)

BUCKETINFO(COUNT)

BUCKETINFO(FSGROUP)

BUCKETINFO(JOBCLASS)

BUCKETINFO(JOBPROJ)

BUCKETINFO(OSGROUP)

BUCKETINFO(PRIORITY)

BUCKETINFO(RESOURCES)

BUCKETINFO(USER)

BUCKETINFO(XDUR)

BUCKETINFO(maxidle)

BUCKETINFO(maxlife)

BUCKETINFO(taskerAutokill)

BUCKETINFO(taskerCmd)

BUCKETINFO(taskerReservation)

BUCKETINFO(taskerResources)

The user can set values in vovaccel.tcl.

http.minSSLVersion - set the minimum TLS version supported. Defaults to "TLSv1.3". Valid values are TLSv1, TLSv1.1, TLSv1.2, and TLSv1.3

http.maxSSLVersion - set the maximum TLS version supported. Defaults to "TLSv1.3". Valid values are TLSv1, TLSv1.1, TLSv1.2, and TLSv1.3

http.tls12Ciphers - this is a list of ciphers that TLS 1.2 and earlier will be restricted to. The default is an empty string, but it can be set to a string such as "ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5"

For an explanation of the string format, see "Cipher List Format" at https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html for details on what's acceptable.

http.tls13Ciphers - This is a list of cipher SUITES that is used by TLS 1.3 (and presumably above if newer TLS versions are introduced in the future) See the description of SSL_set_ciphersuites() at https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_cipher_list.html for an explanation.

By default the value is an empty string, which tells OpenSSL to use the default, which according to the documentation is TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"

Changing any four of these values via vovservermgr config while the server is running will cause the internal webserver to stop and restart with the new configuration. We recommend using a tool such as sslscan that is part of RHEL 8 to verify your changes.

1. The filter is most useful to sort out the jobs/Files. So, it has been moved to down to just above the Jobs/Files table and cause it to search only within the Jobs/Files list.
2. The "Jobs" list has been renamed to "Jobs and Files" because sets contain jobs and files.
3. Added the count of items (both the Jobs and Files) in the "Jobs and Files" list. eg: "Jobs and Files ( 237 )".
4. For files in the Jobs and Files table, omit the Status column has been omitted (leave it blank) and fix has been added to the "Type" column to say "File" instead of the incorrect "Job."

• "never" when times are:
  • specially formatted patterns
  • over 12/31/2099 in the future
  • causing errors when processing
• "expired" - all times are in the past
• <Actual Date> - earliest expiration time in the future

Will NOT show: "some expired" - deprecated

1. When using the tasker configuration path (vtk_tasker_define), ensure that the correct tasker-based procedures are defined and called.
2. Define NC_QUEUE in the indirect tasker's execution environment using the queue name that is specified in the vtk_tasker_nc call, which removes the requirement to create a taskerVNC.tcl in $VOVDIR/local that defines it.
3. Fix major efficiency issue that prevented the indirect tasker from notifying the server that it is ready to accept another job once one has finished.
4. Improve messaging to display the queue name that is being interfaced with for debuggability purposes.