Calling all regressions

[Bron Gondwana]

Hi Simon,

I was particularly interested in your feedback, since you're the most
active package maintainer, and probably responsible for most of our
"long tail" of users of the recent code.  They're the people who are
of most concern for things like configuration changes.  Big sites
tend to have more time to spend getting their config "perfect", but
the little guys just need a turnkey solution that's "good enough"!

On Wed, Mar 11, 2009 at 07:42:17AM +0100, Simon Matter wrote:
> > 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.

Yes, much better if we all have the same defaults.  Plus, anything that
reduces the size of your diff is good.
 
> 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.

How old do we support back until?  The index file upgrade code looks
pretty backwards compatible for approximately ever.  The main issue
with spooldirs is hashing - but I think no hashing _is_ the sane
default.  Ext3 is limited to 32k subdirs, but if your site is that
big you're big enough to read the documentation anyway - and newer
filesystems are better about arbitrary limits too.

> 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.

That's a good idea.  I like it.  Another thing to consider for 2.4!
So basically - you have /etc/imapd.conf and /etc/cyrus.conf (or
whatever) and $configdir/imapd.conf $configdir/cyrus.conf.  Is that
right?

I really should have a look at your RPMs!

> 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?

AAA+++ to cyr_conf!  I'll write it up :)  I think we want it to have the
following spec:

* cyr_conf  - output all configuration variables and their current value
* cyr_conf -C $file - as above with the following config file
* cyr_conf -n $name - all configuration variables for process $name
              (eg cyr_conf -n imapd => show imapd overrides where given)
* cyr_conf -q - only show variables that are different than default

  - those three can be mixed and matched

* cyr_conf -D - show all the DEFAULT variables.  Obviously, ignores all
                other options!

> 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.

Cool.

> 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.

Yep, definitely.  Store them all, and refuse to start unless:
cyr_conf -C $oldfile is the same output as cyr_conf with the
-C option passed to 'master'.  Spit out an error message
describing what's different and how to fix it.

I like :)

Bron.