Enhanced Database Integrity Checks
The ability to check for logical rather than file-system level errors within the Qube databases has been added.
Database Integrity Checks
There are times where the database tables are intact at the file-system level, but contain errors or inconsistent data. To repair these logical errors in the database tables, there are Database Integrity checks available in WranglerView. If there are more than 5000 jobs in the Qube database, the last 2 "Check for jobs" menu items will be prefaced with a "-Long-:"
All checks are enabled if all of the following are true:
- the user has been granted the qube admin privilege
- WranglerView is running on the supervisor
If you're a qube admin on a remote machine (like most wranglers), you can still perform some checks, the ones that are disabled not only check but clean up as well.
Lights Out Management Command Support
Out-of-band management (also known as Lights out management (LOM)) allows a system administrator to monitor and manage servers and other network equipment by remote control.
WranglerView can now leverage your existing LOM framework.
Out-Of-Band Host Management
Out-of-band management (also known as Lights out management (LOM)) involves the use of a dedicated management channel for device maintenance. It allows a system administrator to monitor and manage servers and other network equipment by remote control regardless of whether the machine is powered on, or if an operating system is installed or functional.
LOM is implemented either by a vendor-specific protocol or an industry-(mostly)-standard protocol known as the Intelligent Platform Management Interface (IPMI).
IPMI Overview
The Intelligent Platform Management Interface is a standardized computer system interface used by system administrators for out-of-band management of computer systems and monitoring of their operation. It is a way to manage a computer that may be powered off or otherwise unresponsive by using a network connection to the hardware rather than to an operating system or login shell.
Many vendors have implemented their own version of IPMI support:
- HP Integrated Lights-Out ( HP's implementation of IPMI)
- Dell DRAC (Dell's implementation of IPMI)
- IBM Remote Supervisor Adapter (IBM's out-of-band management products, including IPMI implementations)
- MegaRAC (AMI's out of band management product and OEM IPMI firmware used in e.g. ASUS, Tyan, Intel and Supermicro motherboards)
There is also the open-source ipmtool.
LOM alternatives to IPMI
- Intel Active Management Technology (AMT, Intel's out-of-band management product, as an alternative to IPMI)
WranglerView uses your existing LOM framework
Since LOM is implemented in so many ways specific to particular vendors and hardware, we've elected to provide more of an agnostic approach rather than try and ship something that works with everything.
The WranglerView preferences dialog has a "Lights Out Management Commands" section where you specify the LOM/IPMI command "template" for each operation. Specifying one or more LOM commands causes menu items to appear or be enabled.
- When at least a single LOM command is specified, a "Remote Worker Management" sub-menu will appear in the worker context menu.
- Only LOM commands that are defined in the preferences are enabled in the "Remote Worker Management" sub-menu
Defining the LOM Commands
The Preferences dialog has a "Lights Out Management Commands" section where you can define LOM commands for various operations. What you enter is specific to your particular implementation of an LOM framework.
Workers in a "Stale" State
When a worker is moved from one machine to another, it's possible to end up with a "stale" entry in Qube!, where there are 2 workers with the same host name but different MAC addresses; the newer host is usually active and the old host is usually in a 'down' state.
The problem, and how it happens
If you've ever retired the Qube! worker off of an older machine and re-used the hostname on a newer machines, you've most likely ended up with 2 worker records in the database with the same hostname, but different MAC addresses. The newer (and running) worker will be in an active state, while the worker entry for the older (retired) worker will forever be in a down state, but not be visible in the WranglerView Worker view.
They will be visible in the output from the command-line utility qbhosts:
VM-Win7-x64 00:FF:A0:7D:4C:A8 10.0.1.153 active 0/2 /modelVM-Win7-x64 11:22:33:44:55:66 10.0.1.102 down 0/2 /model
Since Qube! uses the worker MAC address as the primary identifier, it's possible to have more than 1 worker appear in the list with the same hostname, but they will each have a different MAC address. This can be problematic for actions that take the worker's hostname to specify which worker to perform the action on.
In previous versions of WranglerView, these duplicate (and most likely decommissioned) host entries were filtered out of the worker list displayed in the WranglerView Worker View, and would result in a warning message printed to the WranglerView log pane such as:
This made it very difficult for the user to actually remove these workers from the database, and the Qube! administrator was forced to run a command-line utility to remove these workers.
Stale workers
WranglerView will now show these workers in a new "Stale" state with a light tan highlight.
The context menu for these hosts will only have the 'Remove' option enabled, all other options will be greyed out.
If you select multiple workers, and at least 1 worker is in a "stale" state, all options other than 'Remove' will be disabled.
New 'Failing' and 'Retrying' pseudo-states
Added 'retrying' and 'failing' pseudo-states for running jobs that have either failed or running frames that have been automatically retried.
Jobs can be submitted blocked until a certain time of day
Modo support added
There is now job submission from inside Modo:
Arnold support added to Maya and also rendering with SolidAngle's 'kick' utility.
"Browse" buttons for reservations should show global options
