Improved several man pages and deleted unused doc/configuration.pod and getnodecfg
git-svn-id: https://svn.code.sf.net/p/xcat/code/xcat-core/trunk@969 8638fb3e-16cb-4fca-ae20-7b5d299a9bcd
This commit is contained in:
bp-sawyers
parent
6e8b437328
commit
7a13c7b00a
@ -1,27 +0,0 @@
|
||||
=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.
|
||||
@ -155,8 +155,37 @@ where mgmtnode is the hostname of the management node adapter on the cluster sid
|
||||
|
||||
=back
|
||||
|
||||
xCAT also supports regular expressions in the tables. This enables one row to represent many
|
||||
rows. For example, if you have many blades in your cluster and their hostnames have a regular
|
||||
The xCAT database 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 generic inheritance
|
||||
(though some calling code may implement inheritance for specific fields, for example
|
||||
nodehm.power inheriting from nodehm.mgt).
|
||||
|
||||
The tables with records typically retrieved by node name have some extra features to enable a more
|
||||
template-based style to be used:
|
||||
|
||||
Any group name can be used in lieu of a node name in the node field, and that record will then
|
||||
be taken to be applicable to any node in that group. 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 node's groups are then used to search for
|
||||
records. If multiple records could apply from two different groups, the precedence is
|
||||
the order the groups are specified in the nodelist table for that node. 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.
|
||||
|
||||
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 B</\z/-bmc/> for a record with node=ipmi to specify that the BMC hostname is derived
|
||||
by appending B<-bmc> to the end of the nodename of every node in the ipmi group.
|
||||
|
||||
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, if you have many blades in your cluster and their hostnames have a regular
|
||||
pattern of blade1, blade2, etc., and your BladeCenter management modules also have a hostname
|
||||
pattern of amm1, amm2, etc., then your B<mp> table could be expressed by the following single row:
|
||||
|
||||
|
||||
@ -1,73 +0,0 @@
|
||||
#!/usr/bin/env perl
|
||||
# IBM(c) 2007 EPL license http://www.eclipse.org/legal/epl-v10.html
|
||||
BEGIN
|
||||
{
|
||||
$::XCATROOT = $ENV{'XCATROOT'} ? $ENV{'XCATROOT'} : -d '/opt/xcat' ? '/opt/xcat' : '/usr';
|
||||
}
|
||||
use lib "$::XCATROOT/lib/perl";
|
||||
use xCAT::Table;
|
||||
use xCAT::NodeRange;
|
||||
use IO::Socket::SSL;
|
||||
use XML::Simple;
|
||||
$XML::Simple::PREFERRED_PARSER='XML::Parser';
|
||||
use Data::Dumper;
|
||||
use strict;
|
||||
my $xcathost='localhost:3001';
|
||||
if ($ENV{XCATHOST}) {
|
||||
$xcathost=$ENV{XCATHOST};
|
||||
}
|
||||
|
||||
my $server = IO::Socket::SSL->new(
|
||||
PeerAddr=>$xcathost,
|
||||
SSL_key_file=>$ENV{HOME}."/.xcat/client-key.pem",
|
||||
SSL_cert_file=>$ENV{HOME}."/.xcat/client-cert.pem",
|
||||
SSL_ca_file => $ENV{HOME}."/.xcat/ca.pem",
|
||||
SSL_use_cert => 1,
|
||||
#SSL_verify_mode => 1,
|
||||
);
|
||||
die "Connection failure: $!\n" unless ($server);
|
||||
my $target=shift(@ARGV);
|
||||
my %request=(); #Start building the hash to XML-ify
|
||||
$request{command}='getnodeattributes';
|
||||
$request{noderange}=$target;
|
||||
|
||||
for (@ARGV) {
|
||||
my $temp;
|
||||
my $table;
|
||||
my $column;
|
||||
my $value;
|
||||
($table,$column) = split('\.',$_,2);
|
||||
$request{table}=$table; #build/reuse request specific elements
|
||||
$request{attribute}=$column;
|
||||
print $server XMLout(\%request,RootName => 'xcatrequest',NoAttr => 1);
|
||||
alarm(30);
|
||||
my $response;
|
||||
while (<$server>) {
|
||||
alarm(0);
|
||||
$response .= $_;
|
||||
if ($response =~ m/<\/xcatresponse>/) {
|
||||
my $reply=XMLin($response);
|
||||
$response="";
|
||||
if ($reply->{error}) {
|
||||
printf "ERROR: ".$reply->{error}."\n";
|
||||
}
|
||||
if ($reply->{warning}) {
|
||||
printf "Warning: ".$reply->{warning}."\n";
|
||||
}
|
||||
if ($reply->{attributes}{$column}) {
|
||||
printf "$table.$column:".$reply->{attributes}{$column}."\n";
|
||||
}
|
||||
if ($reply->{serverdone}) {
|
||||
last;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
#my $tab = xCAT::Table->new($table,-create => 1);
|
||||
#my $rec = $tab->getAttribs($key,$val,$column);
|
||||
|
||||
# if ($rec->{$column}) { printf $rec->{$column}."\n"; }
|
||||
#}
|
||||
@ -1,15 +1,12 @@
|
||||
=head1 NAME
|
||||
|
||||
B<dumpxCATdb> - dumps the xCAT db tables .
|
||||
|
||||
|
||||
B<dumpxCATdb> - dumps the xCAT db tables .
|
||||
|
||||
=head1 SYNOPSIS
|
||||
|
||||
I<dumpxCATdb [-h| --help]>
|
||||
|
||||
I<dumpxCATdb [-v| --version]>
|
||||
B<dumpxCATdb> [{B<-p>|B<--path>} I<path>]
|
||||
|
||||
|
||||
I<dumpxCATdb[-p| --path]>
|
||||
B<dumpxCATdb> [B<-h>|B<--help>] [B<-v>|B<--version>]
|
||||
|
||||
|
||||
=head1 DESCRIPTION
|
||||
@ -21,9 +18,9 @@ The dumpxCATdb command creates .csv files for all xCAT database tables and puts
|
||||
|
||||
B<-h> Display usage message.
|
||||
|
||||
B<-v> Command Version.
|
||||
B<-v> Command Version.
|
||||
|
||||
B<-p> Path to the directory to dump the tables.
|
||||
B<-p> Path to the directory to dump the tables.
|
||||
|
||||
|
||||
=head1 RETURN VALUE
|
||||
@ -34,14 +31,14 @@ B<-p> Path to the directory to dump the tables.
|
||||
|
||||
=head1 EXAMPLES
|
||||
|
||||
1. To dump the xCAT database into the /tmp/db directory, enter:
|
||||
1. To dump the xCAT database into the /tmp/db directory, enter:
|
||||
|
||||
I<dumpxCATdb -p /tmp/db>
|
||||
B<dumpxCATdb -p /tmp/db>
|
||||
|
||||
|
||||
|
||||
=head1 FILES
|
||||
|
||||
|
||||
/opt/xcat/sbin/dumpxCATdb
|
||||
|
||||
|
||||
@ -51,4 +48,4 @@ This command is part of the xCAT software product.
|
||||
See restorexCATdb
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,29 +1,26 @@
|
||||
=head1 NAME
|
||||
|
||||
B<restorexCATdb> - restores the xCAT db tables .
|
||||
|
||||
|
||||
B<restorexCATdb> - restores the xCAT db tables .
|
||||
|
||||
=head1 SYNOPSIS
|
||||
|
||||
I<restorexCATdb [-h| --help]>
|
||||
|
||||
I<restorexCATdb [-v| --version]>
|
||||
B<restorexCATdb> [{B<-p>|B<--path>} I<path>]
|
||||
|
||||
|
||||
I<restorexCATdb[-p| --path]>
|
||||
B<restorexCATdb> [B<-h>|B<--help>] [B<-v>|B<--version>]
|
||||
|
||||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
The restorexCATdb command restores the xCAT database tables from the directory given by the -p flag.
|
||||
The restorexCATdb command restores the xCAT database tables from the directory given by the -p flag.
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
|
||||
B<-h> Display usage message.
|
||||
|
||||
B<-v> Command Version.
|
||||
B<-v> Command Version.
|
||||
|
||||
B<-p> Path to the directory containing the database restore files.
|
||||
B<-p> Path to the directory containing the database restore files.
|
||||
|
||||
|
||||
=head1 RETURN VALUE
|
||||
@ -34,14 +31,14 @@ B<-p> Path to the directory containing the database restore files.
|
||||
|
||||
=head1 EXAMPLES
|
||||
|
||||
1. To restore the xCAT database from the /tmp/db directory, enter:
|
||||
1. To restore the xCAT database from the /tmp/db directory, enter:
|
||||
|
||||
I<restorexCATdb -p /tmp/db>
|
||||
B<restorexCATdb -p /tmp/db>
|
||||
|
||||
|
||||
|
||||
=head1 FILES
|
||||
|
||||
|
||||
/opt/xcat/sbin/restorexCATdb
|
||||
|
||||
|
||||
@ -51,4 +48,4 @@ This command is part of the xCAT software product.
|
||||
See dumpxCATdb
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1,29 +1,28 @@
|
||||
=head1 NAME
|
||||
|
||||
B<rnetboot> - Will force an unattended network install for a range of nodes.
|
||||
B<rnetboot> - Cause the range of nodes to boot to network.
|
||||
|
||||
=head1 SYNOPSIS
|
||||
|
||||
I<rnetboot [-h| --help]>
|
||||
B<rnetboot> [B<-V>|B<--verbose>] I<noderange>
|
||||
|
||||
I<rnetboot [-v| --version]>
|
||||
|
||||
I<rnetboot [-V| --verbose] noderange>
|
||||
B<rnetboot> [B<-h>|B<--help>] [B<-v>|B<--version>]
|
||||
|
||||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
The rnetboot command will force an unattended network install for a range of nodes.
|
||||
The rnetboot command will do what is necessary to make each type of node in the given noderange
|
||||
boot from the network. This is usually used to boot the nodes stateless or to network install
|
||||
system p nodes.
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
B<-V> Verbose output.
|
||||
|
||||
B<-h> Display usage message.
|
||||
|
||||
B<-v> Command Version.
|
||||
|
||||
B<-V> Verbose output.
|
||||
|
||||
|
||||
=head1 RETURN VALUE
|
||||
|
||||
@ -34,14 +33,10 @@ B<-V> Verbose output.
|
||||
|
||||
=head1 EXAMPLES
|
||||
|
||||
rnetboot 1,3
|
||||
rnetboot 14-56,70-203
|
||||
rnetboot 1,3,14-56,70-203
|
||||
rnetboot all,-129-256
|
||||
|
||||
|
||||
|
||||
|
||||
B<rnetboot 1,3>
|
||||
|
||||
B<rnetboot 14-56,70-203>
|
||||
|
||||
B<rnetboot 1,3,14-56,70-203>
|
||||
|
||||
B<rnetboot all,-129-256>
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
=head1 NAME
|
||||
|
||||
B<mkrrnodes> - Adds or deletes nodes in the xCAT cluster database.
|
||||
B<mkrrnodes> - Sample tool for adding or deleting many nodes in the xCAT cluster database.
|
||||
|
||||
|
||||
=head1 SYNOPSIS
|
||||
|
||||
B<mkrrnodes> [-d ]| [-C a|b|,...,r] -R [startrange,endrange]
|
||||
B<mkrrnodes> [B<-d> ]| [B<-C> I<a|b|,...,r>] B<-R> I<startrange,endrange>
|
||||
|
||||
|
||||
B<mkrrnodes> [B<-h> | B<--help>]
|
||||
@ -13,13 +13,37 @@ B<mkrrnodes> [B<-h> | B<--help>]
|
||||
|
||||
=head1 DESCRIPTION
|
||||
|
||||
The mkrrnodes add or delete (-d) the nodes requested by inputting the CU name (-C) flag and the start and end range (-R) flag. It will also automatically define required nodegroups.
|
||||
The B<mkrrnodes> command is a sample tool that adds or deletes (-d) nodes according to a specific
|
||||
naming convention. You can input the connected unit name (CU, a subset of the cluster, usually in its own
|
||||
subnet and managed by an xCAT service node) using the -C flag, and you can input the start and end
|
||||
range using the -R flag. It will also automatically define required nodegroups.
|
||||
|
||||
In this example tool, the node names will have the format:
|
||||
|
||||
B<rr>I<x048y>
|
||||
|
||||
where:
|
||||
x is a-z, indicating the CU name
|
||||
048 is the node number within that CU
|
||||
y is a-c, indicating which of 3 blades within the "triblade" group it is
|
||||
|
||||
=head1 OPTIONS
|
||||
|
||||
|
||||
=over 10
|
||||
|
||||
=item B<-C> I<char>
|
||||
|
||||
A single letter designating which CU (connected unit).
|
||||
|
||||
=item B<-R> I<start,end>
|
||||
|
||||
The numeric start and end of the range of nodes to create.
|
||||
|
||||
=item B<-d>
|
||||
|
||||
Delete the nodes instead of adding them.
|
||||
|
||||
=item B<-h|--help>
|
||||
|
||||
Display usage message.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user