Integration Guides › BFC API Reference Guide › Grid Record

Grid Record

The grid record is used for both simple grid create where minimum information is specified and for complex grid create where the user has explicit control and fully specifies all attributes for the grid rather than allowing the system to implicitly specify some of the information. The grid record passed as the payload to the grid creation API contains the following fields:

Field	Type	Description
comp_id	integer	Read-only field that contains the resource component ID for the grid resource.
id	integer	The CA AppLogic® grid ID. Valid values are 1-31, but may be further constrained by the grid IDs that were specifically configured for use by the BFC being operated upon.
name	string	The name associated with the grid.
description	string	A description of the grid.
state	string	Read-only field that contains the resource state of the grid, for example, resource_allocated_state, resource_running_state, resource_stopped_state.
applogic_version	string	The CA AppLogic® version associated with this grid, for example, 3.1.9. This field appears as the name field in the version record returned via a BFC API GET operation to the versions URI.
applogic_hotfixes	list of string	A list of hotfixes and/or language packs that have been applied to the grid. On create, it specifies the set of hotfixes and/or language packs that should be applied to the grid. On read, it returns the hotfixes and/or language packs that have been applied to the grid.
oem_kit	string	The name of an OEM Kit uploaded to the BFC for branding the CA AppLogic® Grid Web Access.
xen_config	grid_server_configuration record	A record with fields: min, target, max and selection_criteria which are the xen SLA minimum, target, and maximum number of servers for this grid, plus an expression for the server selection criteria.
esx_config	grid_server_configuration record	A record with fields: min, target, max and selection_criteria which are the ESX SLA minimum, target, and maximum number of servers for this grid plus an expression for the server selection criteria.
Servers	list of server boot MAC addresses	A read-only list of boot NIC MAC addresses associated with the servers currently allocated to the grid. In a future release, you can use these MAC addresses to retrieve more detailed information about each server in the grid.
external_network	string	The base address and CIDR of the network from which application IP addresses are allocated, for example, 127.10.10.0/24.
app_ips	list of grid_ip_range records	The application IP addresses reserved for use by this grid's set of applications. Each range identifies the subnet (a read-only field that is the subnet component ID), the VLAN ID for the range (if any), whether the range is public or private, and the range low and high IP address. When specified on input to either a grid create or a grid update operation, the application IP ranges specified are the exact ranges that will be set on the grid and will replace the ranges currently set. Also, on create, this field and the numAppIPs query string parameter are mutually exclusive, only one or the other may be specified. The numAppIPs query string is not supported on update.
app_ip_count	integer	This is a read-only field that contains the number of application IP addresses reserved for use by the grid's applications. It reflects the actual number of IPs allocated to the grid, whether they were specified explicitly by the user or selected by the system due to the user specifying the numAppIPs query string parameter to the grid creation operation.
controller_ip	string	The IP address that should be or is assigned to the AppLogic grid controller.
default_vlan	integer	The default VLAN used by applications on the grid. Valid range is 1-4094.
account_id	string	The CA AppLogic® account ID for the customer responsible for the grid.
account_key	string	The CA AppLogic® ssh key assigned to the customer responsible for the grid.
vmware_license_key	string	The VMware license key that allows the grid to image servers as ESX servers.
global_user_dir	A grid_global_directory_config record	The user directory service to use for role-based access control (RBAC). Currently, none, LDAP, and Active Directory are the types of directory services supported.
grid_controller_name	string	The hostname for the CA AppLogic® grid controller.
grid_controller_user	string	Input-only field that specifies the username for the initial user configured for the CA AppLogic® grid controller.
grid_controller_password	string	Input-only field that specifies the password for the initial user configured for the CA AppLogic® grid controller.
recovery_password	string	Input-only field that contains the recovery password for the CA AppLogic® grid controller.
additional_config	list of string	Input-only field containing any additional grid configuration parameters in the form ["key=val",...].
external_storage	external_storage_nfs record	Specification of NFS server/path on which AppLogic volumes will be stored.

Server Selection Criteria Specification

You use grid server selection criteria to qualify and rank available servers. After you create the selection criteria clauses using tags, you can control grid server population. Two types of tags are provided: Tags and Smart Tags. You use a Tag to designate basic server allocation. You use a Smart Tag to identify more granular characteristics for a group of servers. Characteristics you can designate include CPU cores, CPU speed, discovery date, memory, power type, and total disk capacity.

When tags are present, they are applied in addition to the minimum server requirements imposed by the CA AppLogic® version you select for the grid.

Tags are combined in Conjunctive Normal Form (CNF) clauses to define a set of tests used as the server selection criteria for the grid. The syntax for specifying selection criteria requires translating CNF-specified tests into a (JSON) array of disjointed literals (ORed in priority order) within a list representing the conjunction. Literals within the CNF clauses represent constraints for requirements (that is, Tag names) or disallowed conditions (negated Tag names).

The following examples use hypothetical sets that represent tag selection criteria. You then use CNF statements to yield selection criteria values.

Example 1

In this example you have server tags defined for the members of the following three sets:

Material: Platinum, Gold, Silver, Bronze
Color: Red, Green, Blue
Shape: Circle, Triangle

Next, assume that you want to designate server criteria for you grid so that the Platinum server is selected before a Gold or Silver server, irrespective of color. In this example, the grid cannot accept a Bronze or Triangle server.

In CNF this is written as:

((Platinum or Gold or Silver) and (not Triangle))

This yields the following selection criteria value:

[["Platinum","Gold","Silver"],["~Triangle"]]

Note that the terms "and" and "or" are absent from the syntax. A conjunction of disjunctions is assumed by using CNF and thus they are implied by the syntax..

This is interpreted as the following, in which each line is tried until enough servers are found to satisfy the grid deficit:

Choose a Platinum that is not a Triangle
Choose a Gold that is not a Triangle
Choose a Silver that is not a Triangle

Example 2:

In this example, you decide that a Red server is better than a Blue or Green server. Also, a Yellow tag has been added, but you want to designate that Yellow servers will not work for the grid.

The selection value now becomes:

[["Platinum","Gold","Silver"],["Red","~Yellow"],["~Triangle"]]

This is interpreted as follows:

Choose a Platinum Red that is not a Triangle
Choose a Platinum that is not Yellow and not a Triangle
Choose a Gold Red that is not a Triangle
Choose a Gold that is not Yellow and not a Triangle
Choose a Silver Red that is not a Triangle
Choose a Silver that is not Yellow and not a Triangle

Example 3:

You could modify the grid selection illustrated in example 2 to add the criteria that the grid exclude not only Yellow servers, but also prefer Blue over Green servers. The selection value can be changed to the following:

[["Platinum","Gold","Silver"],["Red","Blue","Green"],["~Triangle"]]

This will cause the BFC to find servers in the following order until enough servers are found:

Choose a Platinum Red that is not a Triangle
Choose a Platinum Blue that is not a Triangle
Choose a Platinum Green that is not a Triangle
Choose a Gold Red that is not a Triangle
Choose a Gold Blue that is not a Triangle
Choose a Gold Green that is not a Triangle
Choose a Silver Red that is not a Triangle
Choose a Silver Blue that is not a Triangle
Choose a Silver Green that is not a Triangle

Example 4

In this example, the shape criteria include Circles instead of disqualifying Triangles:

[["Platinum","Gold","Silver"],["Red","Blue","Green"],["Circle"]]

This has the following effect on the selection:

Choose a Platinum Red Circle
Choose a Platinum Blue Circle
Choose a Platinum Green Circle
Choose a Gold Red Circle
Choose a Gold Blue Circle
Choose a Gold Green Circle
Choose a Silver Red Circle
Choose a Silver Blue Circle
Choose a Silver Green Circle

Example 5

When you choose to use negation in server criteria, consider the behavior if and when members of a Tag category change. For example, think of what servers would be selected by the above queries if a Square was added as a shape. Also, consider how unknowns are handled. It is quite a bit different to request a server not be a Triangle when there are only Circles and Triangles. Once there are Squares they will be added to Grid1 with the same likelihood as a Circle unless the above refinement to call out Circles explicitly is used.

In the following example, the grid only requires that its servers are not Gold and that they are not Circles.

In CNF this is written as:

((not Gold) and (not Circle))

This is translated to the following selection string:

[["~Gold"],["~Circle"]]

If Gold servers were mistakenly excluded the criteria is modified to:

[["~Circle"]]