The Allocation Manager

The Allocation Manager provides a single point for creating, inspecting, and delegating allocations.

Using the Allocation Manager

Performing an allocation is more than just allocating against a device; the allocation process involves searching for a device that will satisfy the allocation, making the allocation itself, and then storing the allocation such that it can be deallocated at some later arbitrary time. The Domain Manager uses the Allocation Manager to resolve allocations during application deployment. For example, if an application requires a specific resource, during deployment, the Allocation Manager searches the domain for resources that satisfy the requirement. Alternatively, the Allocation Manager can also be used programmatically through the Allocation Manager interface and the REDHAWK API.

Creating Allocations

The REDHAWK FrontEnd Interfaces (FEI) specification is a powerful tool that allows developers to generalize the selection of RF hardware for use by the system applications. Although it is possible to create any allocation, the set of allocations associated with FEI is the only standardized set of allocations in REDHAWK. While associating a specific FEI allocation with an application is useful, so is creating allocations to be used at a system level (beyond the scope of just one application).

To create a new FEI allocation, use the following Python code (assuming an FEI device is running, in this case, the FmRdsSimulator):

 >>> import frontend
 >>> from ossie.cf import CF
 >>> alloc = frontend.createTunerAllocation(center_frequency=100e6, bandwidth=0.0, sample_rate=0.0, returnDict=False)
 >>> requestId = 'my_request'
 >>> pools = []
 >>> devices = []
 >>> sourceId = 'my_script'
 >>> request = CF.AllocationManager.AllocationRequestType(requestId, [alloc], pools, devices, sourceId)

The following table describes the parameters used in this Python code.

Parameters

The Allocation Manager uses the parameters requestId and sourceId to help manage the allocations. For example, in complex systems with multiple subsystems, to manage all the allocation requests for a single application, requestId would be used. If an allocated device unexpectedly terminates, sourceId can be used to determine which allocations are no longer used by any subsystem and then the allocations can be deallocated. Because such management/cleanup is CONOP-specific, it is outside the scope of REDHAWK and must be implemented by system developers to suit their unique needs and environment.

Once the allocation is formulated, a list of requests can be submitted to the Allocation Manager using the allocate method. The allocate function returns a list of AllocationStatusType. This list contains one status for each successful allocation, along with the original allocation properties requested as well as the resulting Allocation ID. This AllocationProperties member can be useful when inspecting FEI allocations because it contains the values requested in the allocation. The response also contains the Allocation ID (generated by the Allocation Manager to guarantee uniqueness within the context of the Allocation Manager). This is required because requestIds can be duplicated. If the request is successful, it is added to the Allocation Manager's allocations list.

The following Python code demonstrates a successful allocation using the allocation request in the previous code example. In this case, a response is returned; the response contains the submitted request ID. The allocation is then deallocated by using the deallocate function on the Allocation Manager; the only required argument is the Allocation ID because that Allocation ID is unique to the Allocation Manager.

 >>> from ossie.utils import redhawk
 >>> domain = redhawk.attach()
 >>> am = domain.getAllocationMgr()
 >>> responses = am.allocate([request])
 >>> response = responses[0]
 >>> print response.requestID
'my_request'
 >>> print response.allocationID
'DCE:d46ce82b-31de-4010-95de-435aaa1f17c5'
 >>> am_allocs = am.allocations()
 >>> print len(am_allocs)
1
 >>> print am_allocs[0].sourceID
'my_script'
 >>> print am_allocs[0].allocationID
'DCE:d46ce82b-31de-4010-95de-435aaa1f17c5'
 >>> am.deallocate([am_allocs[0].allocationID])
 >>> print len(am.allocations())
0

For allocations against an FEI device, the allocatedDevice member of the AllocationStatusType can be used to inspect the tuner status structure. The tuner status structure provides the actual values that were allocated, which may be different from what was originally requested.

Inspecting Allocations through the Python Sandbox

To inspect the current allocations through the Python sandbox:

First, a reference to the running domain is needed. From the Domain Manager, the Allocation Manager can be retrieved:

 >>> from ossie.utils import redhawk
 >>> domain = redhawk.attach()
 >>> am = domain.getAllocationMgr()

If no applications are running, an application must be specified.

 >>> domain.createApplication('/waveforms/rh/basic_components_demo/basic_components_demo.sad.xml','hello')
 <ossie.utils.redhawk.core.App object at 0x33092d0>

In this case, the default basic_components_demo application was selected. This application instance was given the name "hello" to simplify the subsequent output.

The Allocation Manager tracks which device has a component assigned to it, even if no explicit allocations against the device were made. In the case of basic_components_demo, there are a total of six components on the waveform. Viewing the current allocations on the Allocation Manager yields a list of six allocations:

 >>> allocs = am.allocations()
 >>> len(allocs)
 6

Each allocation description returned is a CF.AllocationManager.AllocationStatusType instance, which contains the Allocation ID, requesting domain, any properties allocated, the device that satisfied the allocation, the Device Manager that hosts the device that satisfied the allocation, and the ID for the requester for the allocation.

 >>> allocs[0]
 CF.AllocationManager.AllocationStatusType(allocationID='DCE:15c3ad3e-dbfa-48b6-b0d7-c12b450f9806', requestingDomain='REDHAWK_DEV', allocationProperties=[], allocatedDevice=<ossie.cf.CF._objref_ExecutableDevice object at 0x28cc110>, allocationDeviceManager=<ossie.cf.CF._objref_DeviceManager object at 0x28cc250>, sourceID='DCE:d4d99400-1a11-11e5-a6ce-3417ebc4aab5:hello_1')
 >>> allocs[0].allocationProperties
 []
 >>> allocs[0].sourceID
 'DCE:d4d99400-1a11-11e5-a6ce-3417ebc4aab5:hello_1'

In this example, allocationProperties is an empty list because the deployment required the device to match an allocation requirement and no explicit capacity allocation was made. The source ID is a concatenation of the application's sad.xml file softwareassembly id (the file's globally unique identifier), a ":", and the application name followed by an instance number.

Inspecting Allocations using the IDE

To inspect the current allocations using the IDE:

1. In the REDHAWK Explorer view, right-click a Domain Manager and select Allocation Manager.

   The Allocation Manager view is displayed. The following figure displays the Allocation Manager view based on the results of following the instructions in Inspecting Allocations through the Python Sandbox

   

2. To view the allocation properties associated with an allocation, select the allocation in the Allocation Manager view.

   The Properties view displays the allocation properties.

   The following figure displays the allocation properties from an FEI device allocation.

   

3. To view the device associated with an allocation, from the Allocation Manager view, right-click the allocation and select Find Device.

   The device is highlighted in the REDHAWK Explorer view.

4. To view the Device Manager associated with an allocation, from the Allocation Manager view, right-click the allocation and select Find Device Manager.

   The Device Manager is highlighted in the REDHAWK Explorer view.

Delegating Allocations

If an allocation resolution cannot be satisfied, the Allocation Manager delegates an available resource.

A Domain Manager can register with other Domain Managers. If a Domain Manager is registered with another Domain Manager, then any usesdevice relationship allocation that cannot be satisfied by the Domain Manager is delegated to the remote Domain Managers. Through these registrations, it is possible for multiple Domains to share hardware resources. Sharing between Domains is limited to non-computing resources, like FEI devices. The AllocationStatusType instance returned by the allocate function on the Allocation Manager includes a requestingDomain member. The requestingDomain member shows the name of the Domain Manager that performed the allocation request that is currently satisfied by this Allocation Manager.

To perform multi- domain allocations, a Domain Manager first needs to be registered with a remote Domain Manager:

 >>> domain_1 = redhawk.attach('First_Domain', location='<<some IP address>>')
 >>> domain_2 = redhawk.attach('Second_Domain', location='<<some other IP address>>')
 >>> domain_1.registerRemoteDomainManager(domain_2.ref)

In this example, once the Domain Manager is registered, any allocations made onto domain_1 that cannot be satisfied by domain_1, are then delegated to domain_2.

The allocate function on the Allocation Manager returns a list of all allocations. To simplify this list, the Allocation Manager also contains the localAllocations function, which returns a list of all allocations that were requested and satisfied by this local domain.