28 lines
3.2 KiB
Plaintext
28 lines
3.2 KiB
Plaintext
|
=pod
|
||
|
|
|
||
|
|
=head1 xCAT configuration core architecture
|
||
|
|
|
||
|
|
xCAT configuration spans a number of tables, some with records associated with particular nodes (such as nodelist and nodehm) and others that do not have a direct relationship with any given node.
|
||
|
|
|
||
|
|
The tables not associated with a given node are straightforward, the data is stored and retrieved as-is from the database without interpretation, and without any configuration layer inheritance (though some calling code may have an internal concept of inheritance with such fields, the core configuration will have no facilities to explicitly aid this.
|
||
|
|
|
||
|
|
The tables with records typically retrieved by node name have some extra features to enable a more template-based style to be used:
|
||
|
|
|
||
|
|
=over
|
||
|
|
|
||
|
|
=item *
|
||
|
|
|
||
|
|
Any tagname can be used in lieu of a node name under the node field, and that record will then be taken to be applicable to any node with that tag. If a field is requested for a specific node, and either a record doesn't exist specifically for that nodename or a record exists, but has no definition for the requested field, that nodes tags are then used to search for general level records. If multiple records could apply from two different tags, the precedence is TBD. This is nearly identical to most xCAT 1.x tab file conventions. This is useful in tables such as noderes, where typical configurations have exactly the same field values for large sets of nodes.
|
||
|
|
|
||
|
|
=item *
|
||
|
|
|
||
|
|
xCAT 2 extends the above to be made useful where a field will vary for every node with a given tag, but in ways that would be trivial to describe. If a field is of the format /I<pattern>/I<replacement>/, it is taken to be a perl regular expression, to be performed on the nodename. For example, the bmc field of the ipmi table might be /\z/-bmc/ for a record with node=ipmi to specify that the BMC hostname is derived by appending -bmc to the end of the nodename of every node tagged ipmi. This is useful in tables such as ipmi.
|
||
|
|
|
||
|
|
=item *
|
||
|
|
|
||
|
|
As an extension to the above, a regular expression extended with arithmetic operators is available, by using the format |I<pattern>|I<replacement>|. This behaves similarly to the above, but () enclosed parts in I<replacement> are taken to signify arithmetic operations and substituted in. All operations are integer arithmetic, so 5/4 would come out as 1. The typical perl positional variables are available in such expressions. For example, the mpa field of the mp table for node=blade might be |\D+(\d+)|bc((${1}-1)/14+1)|. Specifically in this case, if you had a node named blade572 tagged blade, the 572 would be set to ${1} by the left hand parentheses, and on the right hand, that would become bc((572-1/14+1)), and finally evaluated and returned as bc41. To complete the example, the id field of mp would be |\D+(\d+)|((${1}-1)%14+1)|, which upon evaluation indicates slot 12. This is useful for tables that call out infrastructure devices/port numbers, such as switch, nodehm (for terminal servers), and mp (for IBM Bladecenter configurations).
|
||
|
|
|
||
|
|
=back
|
||
|
|
|
||
|
|
An administrator may chose to ignore any and all of the functions. For example, an administrator may chose to only make use of the first mentioned feature, and preserve an xCAT 1.x layout for their tables.
|