NAME¶
Config::Model::BackendMgr - Load configuration node on demand
VERSION¶
version 2.061
SYNOPSIS¶
# Use BackendMgr to write data in perl data file
use Config::Model;
use Log::Log4perl qw(:easy);
Log::Log4perl->easy_init($WARN);
# define configuration tree object
my $model = Config::Model->new;
$model->create_config_class(
name => "Foo",
element => [
[qw/foo bar/] => {
type => 'leaf',
value_type => 'string'
},
]
);
$model->create_config_class(
name => "MyClass",
# read_config spec is used by Config::Model::BackendMgr
read_config => [
{
backend => 'perl_file',
config_dir => '/tmp/',
file => 'my_class.pl',
auto_create => 1,
},
],
element => [
[qw/foo bar/] => {
type => 'leaf',
value_type => 'string'
},
hash_of_nodes => {
type => 'hash', # hash id
index_type => 'string',
cargo => {
type => 'node',
config_class_name => 'Foo'
},
},
],
);
my $inst = $model->node->instance( root_class_name => 'MyClass' );
my $root = $inst->config_root;
# put data
my $step = 'foo=FOO hash_of_nodes:fr foo=bonjour -
hash_of_nodes:en foo=hello ';
$root->load( step => $step );
$inst->write_back;
# now look at file /tmp/my_class.pl
DESCRIPTION¶
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 is read during
creation of a node.
This load/store can be done with different "backend":
- cds_file
- 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_file
- INI files (written with Config::Model::Backend::IniFile. See limitations
in "Limitations depending on storage".
- perl_file
- Perl data structure (perl) in a file. See Config::Model::DumpAsData for
details on the data structure.
- custom
- Any format when the user provides a dedicated class and function to read
and load the configuration tree.
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 information back.
Built-in backend¶
"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',
file => 'cfg_file.cds', #optional
},
If "file" is not specified, a file name will be constructed with
"<config_class_name>.<suffix>" where suffix is
"pl" or "ini" or "cds".
Plugin backend classes¶
A plugin backend class can also be specified with:
read_config => [ { backend => 'foo' ,
config_dir => '/etc/cfg_dir'
file => 'foo.conf', # optional
}
]
In this case, this class will try to load
"Config::Model::Backend::Foo". (The class name is constructed with
"ucfirst($backend_name)")
"read_config" can also have custom parameters that will passed
verbatim to "Config::Model::Backend::Foo" methods:
read_config => [ { backend => 'foo' ,
config_dir => '/etc/cfg_dir',
my_param => 'my_value',
}
]
This "Config::Model::Backend::Foo" class is expected to provide the
following methods:
- new
- with parameters:
node => ref_to_config_model_node
"new()" must return the newly created object
- read
- with parameters:
%custom_parameters, # model data
root => $root_dir, # mostly used for tests
config_dir => $read_dir, # path below root
file_path => $full_name, # full file name (root+path+file)
io_handle => $io_file # IO::File object
check => [ yes|no|skip]
Must return 1 if the read was successful, 0 otherwise.
Following the "my_param" example above, %custom_parameters will
contain " ( 'my_param' , 'my_value' ) ", so "read()"
will also be called with "root", "config_dir",
"file_path", "io_handle" and "my_param
=> 'my_value'".
- write
- with parameters:
%$write, # model data
auto_create => $auto_create, # from model
backend => $backend, # backend name
config_dir => $write_dir, # override from instance
io_handle => $fh, # IO::File object
write => 1, # always
check => [ yes|no|skip] ,
root => $root_dir,
backup => [ undef || '' || suffix ] # backup strategy required by user
Must return 1 if the write was successful, 0 otherwise
If "io_handle" is defined, the backup has already been done while
opening the config file. If "io_handle" is not defined, there's
not enough information in the model to read the configuration file and
create the backup. Your write() method will have to do the backup
requested by user.
Custom backend¶
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:
- class
- Specify the class that contain the read method
- config_dir
- Specify configuration directory. This parameter is optional as the
directory can be hardcoded in the custom class. "config_dir"
beginning with '"~"' will be munged so "~" is replaced
by "File::HomeDir->my_data". See File::HomeDir for
details.
- os_config_dir
- Specify alternate location of a configuration directory depending on the
OS (as returned by $^O, see "PLATFORMS" in perlport). For
instance:
config_dir => '/etc/ssh',
os_config_dir => { darwin => '/etc' }
- file
- optional. Configuration file. This parameter may not apply if the
configuration is stored in several files. By default, the instance name is
used as configuration file name.
- default_layer
- Optional. Specifies where to find a global configuration file that
specifies default values. For instance, this is used by OpenSSH to specify
a global configuration file ("/etc/ssh/ssh_config") that is
overridden by user's file:
'default_layer' => {
os_config_dir => { 'darwin' => '/etc' },
config_dir => '/etc/ssh',
file => 'ssh_config'
}
Only the 3 above parameters can be specified in
"default_layer".
- function
- Function name that will be called back to read the file. See "read
callback" for details. (default is "read")
- auto_create
- By default, an exception is thrown if no read was successful. 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.
Write specification is similar to read_specification. Except that the default
value for "function" is "write". Here's an example:
write_config => [ { backend => 'cds_file', config_dir => '/etc/my_cfg/' } ,
{ backend => 'custom', class => 'Bar' ,
function => 'my_write',
},
],
Limitations depending on storage¶
Some storage system will limit the structure of the model you can map to the
file.
Ini files limitation¶
Structure of the Config::Model must be very simple. Either:
- •
- A single class with hash of leaves elements.
- •
- 2 levels of classes. The top level has nodes elements. All other classes
have only leaf elements.
Configuration class with auto read or auto write¶
read specification¶
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:
- •
- First the "cds" file whose name depend on the parameters used in
model creation and instance creation:
"<model_config_dir>/<instance_name>.cds" The syntax
of the "cds" file is described in Config::Model::Dumper.
- •
- A callback to "Bar::read". See ""read callback"
for details.
When a read operation is successful, the remaining read methods will be skipped.
write specification¶
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' } ],
By default, the specifications are tried in order, until the first succeeds.
When required by the user, all configuration information is written back using
all the write specifications. See "write_back ( ... )" in
Config::Model::Instance for details.
The write class declared with "custom" backend must provide a
call-back. See "write callback" for details.
read write directory¶
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¶
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 with binmode :utf8
check => [yes|no|skip]
The IO::File object is undef if the file cannot be read.
The callback must return 0 on failure and 1 on successful read.
write callback¶
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
# with binmode :utf8
auto_create => 1 # create dir as needed
check => [yes|no|skip]
The IO::File object is undef if the file cannot be written to.
The callback must return 0 on failure and 1 on successful write.
CAVEATS¶
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
either to:
- •
- Set "file" to undef or an empty string in the
"write_config" specification.
- •
- Create a "skip_open" function in your backend class that returns
1
EXAMPLES¶
In 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".
Methods¶
write_back ( ... )¶
Try to run all subroutines registered by auto_write_init write the configuration
information until one succeeds (returns true).
You can specify here a pseudo root directory or another config directory to
write configuration data back with "root" and "config_dir"
parameters. This will override the model specifications.
You can force to use a backend by specifying "backend => xxx". For
instance, "backend => 'perl_file'" or "backend =>
'custom'".
You can force to use all backend to write the files by specifying "backend
=> 'all'".
You can force a specific config file to write with "config_file =>
'foo/bar.conf'"
"write_back" will croak if no write call-back are known for this node.
AUTHOR¶
Dominique Dumont, (ddumont at cpan dot org)
SEE ALSO¶
Config::Model, Config::Model::Instance, Config::Model::Node,
Config::Model::Dumper
AUTHOR¶
Dominique Dumont
COPYRIGHT AND LICENSE¶
This software is Copyright (c) 2014 by Dominique Dumont.
This is free software, licensed under:
The GNU Lesser General Public License, Version 2.1, February 1999