Previous Topic: Assembly Descriptor SyntaxNext Topic: Property Markup Syntax


Package Descriptor Syntax

This section contains the following topics:

Package Sub-entity

'class' Sub-entity

'volume' Sub-entity

'protocol' Sub-entity

'resources' Sub-entity

The package descriptor is a table of contents file that defines the contents of an application or of a component library (a catalog). The package descriptor also contains references to volume images that are outside the application's root directory. The application is installed on the grid controller, while the volumes may reside on any of the grid's servers. For applications, it also contains the configuration settings component of the application.

Following are the different types of package descriptors:

application

ToC for an entire application, contains the application's configuration data and references to other package descriptors

catalog

ToC for a catalog (library of components), contains a list of components

recycle, clipboard

ToC for work directories used by the GUI tools. They have a format similar to the catalog package descriptor.

The package descriptor contains one entity of type package.

An application package descriptor may also contain an entity of type 'assembly', with the same structure as the one found in an assembly descriptor, except that it cannot have terminals and properties on the boundary. It is used as the topmost component of the application containing the property settings for the application itself with a single subordinate that is the application's main assembly.

The 'package' entity has the following attributes:

type=

one of: application, catalog, volcache (obsolete), recycle or clipboard.

description=

A human-readable description of the package's contents.

uid=

An ID assigned to the application at the time it was installed. This ID is an integer value in the range 1..254 and is unique among the applications installed on the same cluster of servers.

template=

0/1 designating whether the application is a template. Supported in CA AppLogic 1.2.5

user1=

Free-form user-defined text intended for specifying billing code.

user2=

Free-form user-defined text intended for specifying billing code.

pref_virt_mode=

This is a string that should be one of the following supported VMM modes in CA AppLogic 3.0:

  • xen_pv
  • xen_hvm
  • vmware

If present, it instructs CA AppLogic to use the preferred VMM for all of the application's components that claim to support it (in their 'virtualization/modes=... setting), provided that there is available computing resource (CPU/memory) running under that VMM. The pref_virt_mode attribute DOES NOT support the legacy VMM names 'hvm' and 'paravirt'.

The 'package' entity has the following sub-entities, described in detail below:

package

a reference to another package, which is part of the same application. This is used only if type=application .

class

defines a component class, including the name of the component descriptor file.

volume

a reference to a volume, defining an application-specific data volume. This is used only in application packages

protocol

defines a protocol filter

resources

defines the set of servers on which the application can be scheduled to run. Optionally, resources define the numeric ranges from which IP addresses can be assigned to the components of the application. This is used only in application package descriptors.

Package Sub-entity

The package sub-entity in a package descriptor is a reference to another package. Only application packages can have references to other packages. The references are to catalog packages that are part of the application itself. No references to global catalogs are added to an application's package descriptor.

The following attributes are defined for the package sub-entity:

file=

File name of the sub-package, relative to the directory in which the parent package resides.

type=

The package type, one of: catalog , recycle or clipboard.

'class' Sub-entity

This is a reference to a component class descriptor. The following attributes are defined:

top

Marks the topmost component of the application. This attribute is used for class references in an application descriptor only. The descriptor for the topmost component (which should be an assembly) is in the application's package descriptor file itself.

singleton

Specifies that only a single instance of this component can be used in an application. This attribute is usually specified for all class sub-entities found in an application's package descriptor.

file= name

 

'volume' Sub-entity

The volume sub-entity is a reference to a volume image that is directly assigned for use by a component of the application. No attributes are defined for this entity. Volumes defined in this manner are stored with the application itself (for example, when it is archived, moved or copied). These application volumes are assigned to 'placeholder' volumes of component instances using the regular property setting syntax in an assembly.

Note: The volume entities in a package descriptor are the only explicit reference to volumes that belong to the application.

However, each component class defined in the application scope or in an application-specific catalog also implicitly refers to one or more volumes that belong to the same application. Each volume listed in such components' descriptors with the class attribute has a corresponding 'template' volume, considered an integral part of the application.

'protocol' Sub-entity

The protocol sub-entity is used to define protocol filters. It can display either in a catalog's package descriptor or in an application package descriptor. If any catalog is used in an application, all filters defined in it are available for use in the application - whether by components coming from that catalog or by components defined in the application itself.

If the same protocol filter is defined in more than one package descriptor, all definitions must match exactly.Otherwise an error is reported by the ADL compiler. The well-known protocols' filter definitions are defined in the global catalog that is part of any AppLogic installation. Examples of these include: http, ftp, smtp, and ssh.

The name of each protocol entity is a name that can be used in the protocol= xxx attribute of a terminal. Refer to the component descriptor syntax.

The protocol sub-entity has a single attribute: filter, with a string value that defines the protocol constraints. For example:

   protocol http: filter="tcp_in:80" 

Note: The syntax of the protocol filter string is not part of this specification - it is not interpreted by the ADL compiler.

'resources' Sub-entity

The resources sub-entity defines what is available for the application to use on the grid of servers on which it is installed. It contains the following sub-entities:

servers

The set of servers that is available to the application. Servers has these attributes:
min= min_val - minimum number of servers to assign to the application
max= max_val - maximum number of servers to assign to the application
set=" name1,name2, ... " - optional; if specified, defines a subset of servers that the application may use.

mem,
cpu,
bw

Instead of defining specific servers that can be used by the application, restrictions on the amount of resources that can be used by it can be defined using one or more of the mem, cpu or bw constraints, which have the same syntax as the corresponding resource sub-entities for a component are define the total amount of the corresponding resource that can be made available to the application.

ip

The set of IP addresses available for assignment to terminals of the application's components, defined with these attributes:
base=ipaddr
n=max_addrs
netmask=ipaddr
The n and netmask attributes are optional. If netmask is omitted, it is computed from the high-order byte of the IP address, assuming the standard assignments of class A, B and C addresses. If n is omitted, it is computed from the netmask as the maximum number of valid addresses that the netmask allows for. The IP sub-entity is optional. If not specified, the CA AppLogic build system assigns a subrange of IP addresses from the pool of IP addresses defined in the CA AppLogic configuration file ( applogic.conf ). The global pool of addresses defined in applogic.conf is divided into 256 sub-ranges of equal size, each sub-range is used for one of the installed applications depending on its unique ID number assigned at installation time (see the uid attribute above).