Config::Model::AutoRead - Load configuration node on demand
# top level config file name matches instance name
$model->create_config_class
(
config_class_name => 'OneAutoReadConfigClass',
read_config => [ { backend => 'cds_file' , config_dir => '/etc/cfg_dir'},
{ backend => 'custom' ,
class => 'ProcessRead' ,
config_dir => '/etc/foo', # optional
file => 'foo.conf', # optional
auto_create => 1, # optional
}
],
# if omitted, write_config will be written using read_config specifications
# write_config can be array of hash ref to write several syntaxes
write_config => { backend => 'cds_file', config_dir => '/etc/cfg_dir' } ,
element => ...
) ;
# config data will be written in /etc/my_config_dir/foo.cds
# according to the instance name
my $instance = $model->instance(instance_name => 'foo') ;
This class provides a way to specify how to load or store configuration data within the model (instead of writing dedicated perl code).
With these specifications, all the configuration information are read during creation of a node.
This load/store can be done with any of these backend:
Config dump string (cds) in a file. I.e. a string that describes the content of a configuration tree is loaded from or saved in a text file. See Config::Model::Dumper.
Ini files (written with Config::Tiny. See limitations in "Limitations depending on storage".
Perl data structure (perl) in a file. See Config::Model::DumpAsData for details on the data structure.
XML. Not yet implemented (ask the author if you're interested)
Any format when the user provides a dedicated class and function to read and load the configuration tree.
Data can be loaded or stored using RedHat's Augeas library. See Config::Model::Backend::Augeas for details.
After loading the data, the object registers itself to the instance. Then the user can call the write_back method on the instance (See Config::Model::Instance) to store all configuration informations back.
cds_file, ini_file and perl_file backend must be specified with mandatory config_dir parameter. For instance:
read_config => { backend => 'cds_file' ,
config_dir => '/etc/cfg_dir'},
Custom backend must be specified with a class name that will features the methods used to write and read the configuration files:
read_config => [ { backend => 'custom' ,
class => 'MyRead',
config_dir => '/etc/foo', # optional
file => 'foo.conf', # optional
} ]
custom backend parameters are:
Specify the class that contain the read method
Specify configuration directory. This parameter is optional as the directory can be hardcoded in the custom class.
optional. This parameter may not apply if the configuration is stored in several files. By default, the instance name is used as configuration file name.
Function name that will be called back to read the file. See "read callback" for details. (default is read)
By default, an exception is thrown if no read was successfull. This behavior can be overridden by specifying auto_create => 1 in one of the backend specification. For instance:
read_config => [ { backend => 'cds_file', config_dir => '/etc/my_cfg/' } ,
{ backend => 'custom', class => 'Bar' ,
auto_create => 1
},
],
This feature is necessary to create a configuration from scratch
When set in write backend, missing directory and files will be created with current umask. Default is false.
Some storage system will limit the structure of the model you can map to the file.
Structure of the Config::Model must be very simple. Either:
A configuration class will be declared with optional read_config parameter:
read_config => [ { backend => 'cds_file', config_dir => '/etc/my_cfg/' } ,
{ backend => 'custom', class => 'Bar' },
],
The read backends will be tried in the specified order:
<model_config_dir>/<instance_name>.cds The syntax of the cds file is described in Config::Model::Dumper.Bar::read. See ""read callback" for details.When a read operation is successful, the remaining read methods will be skipped.
A configuration class will be declared with optional write_config parameters (along with read_config parameter):
write_config => [ { backend => 'cds_file', config_dir => '/etc/my_cfg/',
auto_create => 1, },
{ backend => 'custom', class => 'NewFormat' } ],
When required by the user, all configuration informations are written back using all the write specifications. See "write_back ( ... )" in Config::Model::Instance for details.
The write class declared witn custom backend must provide a call-back. See "write callback" for details.
By default, configurations files are read from the directory specified by config_dir parameter specified in the model. You may override the root directory for test.
Read callback function will be called with these parameters:
object => $obj, # Config::Model::Node object root => './my_test', # fake root directory, userd for tests config_dir => /etc/foo', # absolute path file => 'foo.conf', # file name file_path => './my_test/etc/foo/foo.conf' io_handle => $io # IO::File object
The IO::File object is undef if the file cannot be read.
The callback must return 0 on failure and 1 on succesfull read.
Write callback function will be called with these parameters:
object => $obj, # Config::Model::Node object root => './my_test', # fake root directory, userd for tests config_dir => /etc/foo', # absolute path file => 'foo.conf', # file name file_path => './my_test/etc/foo/foo.conf' io_handle => $io # IO::File object opened in write mode auto_create => 1 # create dir as needed
The IO::File object is undef if the file cannot be written to.
The callback must return 0 on failure and 1 on succesfull write.
When both config_dir and file are specified, this class will write-open the configuration file (and thus clobber it) before calling the write call-back and pass the file handle with io_handle parameter. write should use this handle to write data in the target configuration file.
If this behavior causes problem (e.g. with augeas backend), the solution is to:
file or config_dir parameter in the write_config specification.skip_open function in your backend class that returns 1In the example below, only a cds file is written. But, both custom format and cds file are tried for read. This is also an example of a graceful migration from a customized format to a cds format.
read_config => [ { backend => 'cds_file', config_dir => '/etc/my_cfg/' } ,
{ backend => 'custom', class => 'Bar' },
],
write_config => { backend => 'cds_file', config_dir => '/etc/my_cfg/' },
You can choose also to read and write only customized files:
read_config => { backend => 'custom', class => 'Bar'},
Or to read and write only cds files :
read_config => { backend => 'cds_file'} ,
You can also specify more parameters that must be passed to your custom class:
read_config => { backend => 'custom', class => 'Bar',
config_dir => '/etc/foo'},
To migrate from an old format to a new format:
read_config => [ { backend => 'custom',
class => 'OldFormat',
function => 'old_read'
} ,
{ backend => 'custom',
class => 'NewFormat',
function => 'new_read'
}
],
write_config => [ { backend => 'custom',
class => 'NewFormat'
}
],
If write_config is missing, the data provided by read_config will be used. For instance:
read_config => { backend => 'custom',
class => 'Bar',
config_dir => '/etc/foo'
},
In this case, configuration data will be read by Bar::read in directory /etc/foo and will be written back there by Bar::write.
Dominique Dumont, (ddumont at cpan dot org)
Config::Model, Config::Model::Instance, Config::Model::Node, Config::Model::Dumper, Config::Augeas
