Univa Grid Engine 8.1.5 and License Orchestrator 1.0.0 released (2013-07-25)
Since today the next milestone of Grid Engine - UGE 8.1.5 is officially available. It not just contains over 40 important fixes, it is also the first version with built-in support for our new product the Univa License Orchestrator. At the same time we released Univa License Orchestrator 1.0.0. The License Orchestrator can not only manage licenses beyond multiple Grid Engine installations or even when used outside of Grid Engine, it also comes with an interconnection to Flexera, and a broad range of features for license management like fair shares for licenses, license quotas for restricting specific users / groups, external tools (losub) for requesting licenses outside of Grid Engine, accounting and reporting of license usage, a tight integration into UniSight (our web based reporting tool which is shipped with Univa Grid Engine), and reservation of licenses. The integration in UGE 8.1.5 is handled by a special thread called lo_thread which needs to be enabled by qconf -at lo_thread after setting the lo_root qmaster parameter pointing to the license orchestrator installation.
When it comes to improvements then several fixes for qrsh can be mentioned (performance and reliability), advance reservations can now also handle longer durations (a date overflow bug was fixed), the scheduler sorting algorithm got updates and does now a efficient binary search per default (when using slot ranges), on MacOS X launchd support is now enabled as default. We also introduced a new qmaster parameter (ENABLE_REDUCE_MEM_FREE) which allows you to enable that memory requests (mem_free) can be reduced during job runtime with qalter.
With UGE 8.1.5 you can now also specify an estimated runtime for a job without letting the job be signaled when the time is over. Using h_rt (hard runtime limit) and s_rt (soft runtime limit) usually leads to abortion of the job. The signal sent by s_rt can be caught by the job but for this the job needs to be either started by a wrapper script or the job itself must install a signal handler. With the new d_rt no signal is sent which does not required any changes for the job and therefore simplifies setup. Why providing a runtime when it has no effects? Giving the expected runtime is a requirement for resource reservation for example. Setting a global default runtime for the jobs (which also can be configured) is usually not very helpful for the scheduler in that case. Before you can use d_rt you need to initialize d_rt=INFINITY in the global host (qconf -me global -> complex_values d_rt=INFINITY).
Note that 8.1.5 requires a clone upgrade when coming from earlier releases.
More information (the complete issue list) you will find here here.