License Partitioning

On this page

User Rules
Dynamic Users
Partition Rules
Rule Conditions
Public API
License Administrator (hkey)
- Status Indicators

New

This feature was added in License Server 20.0. A client Houdini License Server can still use this feature as long as the License Server is 20.0 or greater.

Licensing partitioning works by splitting users and license seats into “license sets”. A License Sets groups users, license seats and other information together based on various conditions your studio or project may have. For example, your company has multiple studios where by default artists should only be able to access licenses from their assigned studio. In this example you would have license sets “Studio A”, “Studio B”, and so on.

The partitioning system added in Houdini 20.0 should be considered a ground up re-write from the original partition system added in Houdini 18.5. The two systems should not be considered equivalent and Houdini 20.0 does not make any attempt for backwards compatibility. The original partitioning system had several shortcomings such as having to restart sesinetd on each modification, having to hand edit the entire system, and much more.

A license set has a number of attributes that make up the set. These attributes are listed below.

Attribute	Description
User Rule(s)	The rules that define which users have access to the license set. The user rules are considered to be more of a static property unlike the dynamic users list which is meant to be dynamic.
Dynamic User(s)	The dynamic users list is an alternative way to list specific users that have access to the license set. The dynamic users are meant to be drive primarly through the public api whereas the user rules are meant to be driven through hkey.
Partition Rule(s)	The rules that define which licenses and the number of seats that should be included in the license set.

Any user can view the license sets but only users that have administrative can edit the license sets.

User Rules ¶

The user rules specify which users have access to the license set. When a rule is a borrow rule it indicates that the users that match the condition can have access to the license seats but in the event their are no more licenses for non-borrowing users these borrowing users will have their license seat stolen by the non-borrowing users.

Attribute	Explanation
`condition`	The condition a user must meet to match the rule and therefore have access to the license set. A user only has to match one user rule to be included in the license set.
`borrow`	Indicates if users matching this rule should be a borrowing user and therefore they can be kicked out by other non-borrowing users under certain circumstances.

Dynamic Users ¶

In addition to user rules there are dynamic users. These are individually listed users that are typically driven through the public api by a third party system like ShotGrid. Users are listed as username@machine_name and only a direct match is possible. If a request matches a dynamic user and any number of user rules the dynamic user entry is used for the request.

Partition Rules ¶

The partition rules specify which licenses and the specific quantity of seats to include in the license set. If the quantity for a license rule is less than or equal to 0 it indicates there is no limit for the rule which means all available seats that match the condition will be included in the license set.

Attribute	Explanation
`condition`	The condition a license must meet to be included in the license set. A license can be listed in multiple sets but a license seat can only be listed in one license set at a time.
`quantity`	The number of seats from a license that should be included in the license set. A quantity of zero or less indicates all non-partitioned seats for the matched license should be included in the license set.

Rule Conditions ¶

Rule conditions for both user rules and partition rules follow the same syntax and the only difference being that some variables only apply to specific rules.

Supported Types ¶

Rule conditions use basic types in a python style format.

Type	Format
`Decimal`	10.51. Decimals are of the standard decimal format. In fact all numbers are converted to decimals.
`Strings`	`"Hello World!"` or `'SideFX'`. Strings are of the standard string format.
`Arrays`	`[ type, type, ... ]` ex. `[ "Hello World", "Sidefx", "license" ]` or `[ 1.0, 1.2, 1.3 ]`. The type must be the same throughout the array. Currently supported array types are string, decimal, and ip masks.
`IP Mask`	`10.1.1.`, `192.168.+.`. The mask is the standard mask format found in the servers options file or license string. The mask can also be combined with an array to match against a list of masks.

Syntax ¶

Term	Definition
`and` `&&`	Standard and operators.
`or` `\|\|`	Standard or operators.
`==` `!=`	Standard comparison operators.
`in`	Check if an item is found inside another object. This is typically used to check if an object is inside of an array.
`matches`	This allows for comparison of two objects that don’t need to be exactly equal. This is commonly used for regex comparisons.
`>` `<` `>=` `<=`	Standard comparison operators.
`(` `)`	Standard bracket group operators.

Reserved variables ¶

There are several reserved variable names that are used to pull in information from the object that is being compared against. In the case of licenses the version info is available through the variable version.

Administrator Condition Variables ¶

Variable Name	Definition
`ip_address`	The ip address of the client the request came from. This is in IPv4 format (i.e. 127.0.0.1).
`username`	This is the username of the client the request came from. If the client computer name is `user@machine` the username would be `user`.
`machine_name`	This is the username of the client the request came from. If the client computer name is `user@machine` the machine name would be `machine`.

User Rule Variables ¶

Variable Name	Definition
`ip_address`	The ip address of the client the request came from. This is in IPv4 format (i.e. 127.0.0.1).
`username`	This is the username of the client the request came from. If the client computer name is `user@machine` the username would be `user`.
`machine_name`	This is the username of the client the request came from. If the client computer name is `user@machine` the machine name would be `machine`.

Partition Rule Variables ¶

Variable Name	Definition
`product`	This is the licenses product name (i.e. Houdini-Master). The values used are the internal product names and not the product display names. Display names are subject to change and do not support backwards compatibility. For these reasons we use the internal name (i.e. Houdini-Master).
`platform`	This is the platform the license is tied to.
`licenseid`	The license id from the license string.
`version`	The version of the license. This is represented in decimal form as `18.5`. All regular decimal comparison operations are supported (i.e. <=, ==, !=).
`ip_mask`	The ip mask of the license.

An easy way to think of user and partition rules is with the following example. Rules use a limited python like syntax.

"""
example license:
LICENSE Generic Houdini-Master 19.5 1 17-aug-2022 +.+.+.+ serverA abcdefgh @iH8rRBaJ71wYE7bcgBF2izJ2HUIf

example partition rule:
product=='Houdini-Master' and version>=19.5
"""

# If variable condition_matches is True then the license matches the partition
# rule and can be included in the license set.

product="Houdini-Master"
version=19.5
quantity=1
expiry=17-aug-2022
ip_mask=+.+.+.+
license_id=abcdefgh
condition_matches=product=='Houdini-Master' and version>=19.5

Public API ¶

For larger studios they may already have a system setup that defines users split up into different groups (eg. ShotGrid). For these studios you can use your already setup systems like ShotGrid to drive the partitioning system using the public api.

Retrieving license sets is split up into two or more API calls. The first api call retrieves the list of license sets with the response listing the id and names of all license sets. A second api call is made to retrieve the license set information for a single set. A third api call can be made to retrieve the list of dynamic users listed for the license set.

Modifying license sets is split up into multiple api calls for various components of the partitioning system. A complete list of public api calls are listed here.

License Administrator (hkey) ¶

Status Indicators ¶

Icon	Meaning
	The component or license set is out of sync with the license server likely due to a local modification.
	The component or license set is marked for deletion. A publish is required to push the deletion to the license server.
	The component or license set is insync with the license server. No action is required.
	The component or license set is either in the process of loading or publishing changes to the license server and cannot be modified until all outstanding operations are complete.