[augeas-devel] OT: How do Augeas lenses deal with incompatible config file changes on upgrade?

Dominique Dumont domi.dumont at free.fr
Sun Jun 15 09:25:38 UTC 2008


Hello

"Jeff Schroeder" <jeffschroed at gmail.com> writes:
> On Fri, Jun 13, 2008 at 2:13 PM, David Lutterkort <dlutter at redhat.com> wrote:
>> On Fri, 2008-06-13 at 13:07 -0700, Jeff Schroeder wrote:
>>> How does Augeas deal with something like squid where the config file
>>> will change in incompatible ways?
>>> Some of the directives in the rhel4 squid vs rhel5 change and are not
>>> backwards compatible.
>>
>> What exactly are the differences ? Is it possible to detect what version
>> a file is for just from looking at the config file ?
>
> The example for this will be squid 2.5 in rhel4 vs squid 2.6 in rhel5.
> This link summarizes the changes.
> http://ftp.iasi.roedu.net/mirrors/ftp.squid-cache.org/squid-2/STABLE/squid-2.6.STABLE5-RELEASENOTES.html#s2
>
> Squid 2.5 valid directives:
> httpd_accel_host virtual
> httpd_accel_port 80
> httpd_accel_with_proxy on
> httpd_accel_uses_host_header on
>
> Squid 2.6 valid directives:
> http_port 3128 transparent
> http_port 80 vhost
>

There's a possibility with Config::Model[1] (possibly on top of
Augeas)

In short, Config::Model is made of 2 parts:
- a in-memory representation of the configuration structure in its
  values. This representation is made a model declaration. See
  config_sshd model [2] for instance
- a parser/writer which does more or less the same thing as Augeas (I
  hope that David will forgive me this crude summary)

To address the upgrade problem, the model declaration for squid 2.6
would feature a model declaration for both 2.5 and 2.6 features:
- 2.5 parameters would be declared with "status" "deprecated" [3]
- default values of 2.6. parameters would be computed from the
  deprecated 2.5 values (with Config::Model compute feature [4])

The Config::Model parser for squid would be able to load both 2.5 and
2.6 parameters. On the other hand, Config::Model writer for squid
would not able to write back parameter marked deprecated. 

This way, you have a smooth migration path from 2.5 to 2.6 squid
configuration files.

>> Even more difficult is the question of how to get from an 'old' squid
>> config file to a 'new' squid config file. It would be possible to
>> address that with Augeas, and a bit of copying files around, but it's
>> not something anybody has looked at in much detail.
> But it seems like a valid use case for Augeas. 

This problem may be better addressed by a layer above Augeas. I'm
working on Augeas Perl binding, so using Config::Model on top of
Augeas will be possible.

> Especially on debian based distributions where dist-upgrades are
> often encouraged from release to release.  If this technically
> possible without nasty hacks we should "do the right thing TM".

Agreed. I'm beginning to talk with Debian [5]. Let's see how this pans
out.

All the best

[1] http://config-model.wiki.sourceforge.net/
[2]
http://search.cpan.org/src/DDUMONT/Config-Model-OpenSsh-0.104/lib/Config/Model/models/Sshd.pl
[3]
http://search.cpan.org/~ddumont/Config-Model-0.623/lib/Config/Model/Node.pm#Configuration_class_declaration
[4]
http://search.cpan.org/~ddumont/Config-Model-0.623/lib/Config/Model/ValueComputer.pm
[5]
http://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase/Discussion




More information about the augeas-devel mailing list