Calling all regressions

[Simon Matter]

> On Tue, Mar 10, 2009 at 01:33:00PM -0400, Wesley Craig wrote:
>> On 10 Mar 2009, at 08:51, Michael Menge wrote:
>> > I think i should rephrase my question.
>> >
>> > Is there a way for cyrus to know that it was updated
>> > since the last time it did run, so it can do the things
>> > suggested by Bron.
>>
>> Perhaps we should add a config option with no default whose value
>> must be the version of the software you're running.
>
> Hmmm.... v2.3.13-fmsvn18309-5c1c69c4 ;)  It makes inplace updates
> a cow, since cyrus detects the new file and automatically closes
> old processes and starts new ones.  Pretty tricky.
>
> Though a configuration with no default that said "running Cyrus 2.3
> series" would be reasonable.
>
> Actually, I think at this point I would recommend releasing
> Cyrus 2.4 based on our current stable plus this change, and
> require a config variable that said "I'm running Cyrus 2.4".
>
> At this point I would also recommend revisiting EVERY config
> option and making the default be the best value (in our humble
> opinions) rather than the backwards compatible one.  I have
> written about this before - and I think it's a jump we should
> take pretty soon, to get all new users using the best possible
> options without having to maintain a giant config file.

As a package maintainer I would be happy to see some more advanced options
being the default. My rpms have different defaults but that requires
patching not only the options file but also the docs to reflect the
changes. Unfortunately it can still lead to confusion if people "forget"
to read the manpage and other docs.

About the config variable discussed above:
Since my rpms do quite some magick to make upgrades work without any user
intervention, I had this problem for a long time. One should keep in mind
that having old config files is one thing, the other thing are old
configdir/spooldirs. My solution for the latter was to maintain a db
config file in the rpm package, and maintain another db config file in the
configdir. That way the init script evaulates the two db configs and the
imapd config, it they don't match it takes any action it needs and then
writes the new config to the configdir. That way you can also transfer a
configdir/spooldir from another server with different cyrus-imapd version
to the current server and things will still work correctly. Or you can
change imapd.conf and the changes will take effect on the configdir on
startup.

At the moment the db config includes the db version and the sieve version
like this:
annotation_db=skiplist
duplicate_db=skiplist
mboxkey_db=skiplist
mboxlist_db=skiplist
ptscache_db=skiplist
quota_db=quotalegacy
seenstate_db=skiplist
sieve_version=2.2.3
statuscache_db=skiplist
subscription_db=flat
tlscache_db=skiplist

My question is how can all this be implemented in cyrus-imapd without too
many changes. What about having a function to read all current setting
(something like postconf does in postfix) and have cyrus-imapd maintain a
copy of this in the configdir? That way cyrus-imapd or the init script
could check whether both configs match enough and they action or refuse to
start if they don't match. The config file should not only include
configurable options but also internal options like what I did with the
sieve_version to reflect internal changes. Cyrus-imapd does handles a lot
of those changes on the fly but not all, live upgrading sieve scripts, and
those should be found in the configs.

Regards,
Simon