| Posted on 2008-07-22 10:57:09-07 by ddumont |
| Augeas integration leads to some changes... |
|
This is a copy of a mail sent to the config-model-user mailing list Hello To integrate Augeas, I need to make some changes on the "permanent storage" specification. Until now, Config::Model had the notion of "file storage" and the specifications was written with a 'syntax' parameter like this:
'read_config' => [
{
'function' => 'read',
'class' => 'Config::Model::Sshd',
'syntax' => 'custom'
}
],
or
'read_config' => [
{
'function' => 'read',
'syntax' => 'ini' , # for ini style files
}
],
But Augeas is not a syntax, it's a complete library to write files according to a lot of different syntaxes. Once Augeas is integrated in Config::Model, the 'syntax' keyword is misleading. So I'm going to replace 'syntax' with 'backend'. This will leave the possibility to further extend Config::Model to store data in other non-file backend like a database or LDAP. So the new specification will be written like this:
read_config => [ { backend => 'augeas' ,
config_file => '/etc/ssh/sshd_config'
},
{ backend => 'custom' , # fallback if Augeas is not installed
class => 'Config::Model::Sshd'
}
]
Now 'backend' can be ini_file, perl_file, custom, augeas ... This change is backward compatible so current models like OpenSsh will continue to work (with warnings). But the current graphical model editor editor will break with the new specification. Ie. config-model-edit will break. config-edit will work fine. I could modify the model editor to handle the new specification easily, but it would fail to load the old model. So my user/developers would have a problem to upgrade their model from the old syntax to the new syntax. (with -force option, old data can be discarded, but that's not user friendly) Since config-model-edit also uses Config::Model to handle edition (with Config::Model::Itself), this becomes a classical configuration upgrade problem where the new configuration is not compatible with the old one. So, I'm going to use this real use case to experiment on how to address this upgrade problem with Config::Model so that upgrade can be done without user input. I'm going to start with this description of the 'backend':
'syntax' => { type => 'leaf',
value_type => 'enum',
choice => [qw/cds perl ini custom/],
#status => 'deprecated',
status => 'obsolete',
},
'backend' => { type => 'leaf',
value_type => 'enum',
choice => [qw/cds_file perl_file ini_file augeas custom/],
compute => { formula => '$old' ,
variables => { old => '- syntax' } ,
replace => {
perl => 'perl_file',
ini => 'ini_file',
cds => 'cds_file',
},
allow_override => 1,
},
},
Currently, this does not work. But it will be fixed soon. Once it works, this trick can also be used for any kind of configuration where changes can be smoothy handled by config::Model instead of requiring user input. I'll keep you posted on progress All the best |
| Direct Responses: Write a response |
