Scenario: Server-specified Counts

Sometimes, a capability request does not contain any desired features. In this case, the server can be configured to specify the features that should be assigned to a client device. If a reservation exists for the client that sent the capability request, the reserved counts are acquired. The following model reservation example demonstrates how this behavior is replicated with named license pools. The without requested features directive replicates the server-specified count, and all from "license_pool_name" allocates all feature counts from the specified named license pool to the first client sending a capability request that fulfills the conditions defined in the rule of access. The all from "license_pool_name" instruction essentially acts as a shortcut to the feature counts specified for the relevant named license pool in the model definition. If the specified named license pool does not have sufficient counts to satisfy the request, counts are allocated from subsequent named license pools listed in the rules of access (provided that the client has access to those named license pools).

Let’s assume that the original reservation model consists of per-hostid reserved counts, together with the ability to get counts from the default shared pool. An equivalent model definition and rule of access might look like this:

model "reservations" {

partitions {

partition "reservation-1" {

"f1" 1.0 1

}

}

on hostid("F01898AD8DD3/ETHERNET") {

use "reservation-1", "default"

without requested features {

all from "reservation-1"

}

accept

}

}

The without requested features directive can also be combined with a feature specification to produce more fine-grained rules of access. For a use case example, see Use Case: Letting Server Specify Counts .

As noted in the previous scenario, creating rules of access based on hostids is generally not recommended. Instead, consider basing the rules of access on hostname or hosttype properties or vendor dictionary key/value pairs.

Note:Server-specified desired feature counts should be marked with the "partial" attribute, indicating that partial checkout is allowed if the feature’s count falls short of the desired count.

Note:The hostid is specified as a value/type pair (for example, 7200014f5df0/ETHERNET). If a hostid condition does not specify the hostid type, it is assumed that the hostid is of type string.