Future Ideas wiki page

[Wil Cooley]

Bron Gondwana wrote:

>> 1. It would be nice from a provisioning standpoint to be able to enumerate
>> available partitions and their capacities within the IMAP protocol itself. This
>> way, provisioning scripts could decide intelligently which backend and partition
>> to use without resorting to SNMP or SSH or other. Is this something that could
>> be delivered in an annotation or "ID" response perhaps?
> 
> Some of the work Ken did with this (auto-choose-partition) would probably be
> extendable.  I like the idea.

Was this the discussion about the autocreate patch in the last few months? Do
you have any more info about this?

>> How about setting a server shutdown or motd message that applies only to a
>> particular partition? We've had cases where we had to restore a whole partition
>> after some SAN buggery. It would have been nice if we could have locked out or
>> at least provided a message directly to the affected users.
> 
> Hmm... interesting.  Would you do this via the user's INBOX partition?

That's what I was thinking. Shared folders on an affected partition are a case I
haven't considered. Managing it with cyradm would be something like:
  > setinfo --partition XX shutdown "Server having problems. Check back later."

> Now, you see - this is why we just run separate instances on the same machine rather
> than using partitions at Fastmail - you get all this for free, and besides you can
> have the replicas go different places.

That sounds like a work-around for inadequacies in what can be done with
partitions :)

>> Somewhat orthogonally, what about being able to configure separate
>> metapartitions per metadata type for a partition? For example, as you mention on
>> #5 on your list, one metapartition to put the cyrus.index files on a fast SSD
>> and another to put the large squatter files on cheaper, slower storage?
> 
> Yeah, this and database file locations even more so.  It would be great to have
> the statuscache and deliver dbs on tmpfs or similar to avoid the disk IO.

Yes, that would be nice.

>> 4. If you're going to be computing SHA1s for messages anyway, would there be any
>> value in hashing the message files across sub-directories, so that directories
>> wouldn't get to be so large? ...
> 
> Ick.  You could hash by UID just as easily really, least-significant bit(s).
> I saw the response to this - anything that doesn't let you open by explicit
> filename quickly will suck.  See, our backup software reads the cyrus.index
> to choose which files to back up as well - so we never[tm] enumerate the
> directory.  Except for reconstruct of course.

My biggest complaint is having to wait for 'ls' when I am looking at a
directory. I realized after sending this that my problem is really that GNU ls
is sorting the results by default and if I change it to unsorted than it
responds much more quickly.

>> 5. What about toggling whatever CYRUS_VERBOSE enables by sending a signal or
>> something like that? On my test systems I have gotten some good info from that
>> which I would not have otherwise gotten but it is not feasible to enable it on
>> my production systems.
> 
> Hey, that's a cool idea.  Pretty easy too.

Great to hear it! Maybe I should try it...

>> 6. sieveshell: Command to report supported extensions (a little more intuitive
>> than 'nc localhost sieve').
> 
> Sounds great.

Yeah, also probably pretty trivial, I'd guess.

>> 7. Doc additions: (I could do some of these, if I'd make the time...) There are
>> some cyradm commands that, in a Murder setup, need to be run from a front-end or
>> back-end (sometimes a particular back-end). For example, it took me a while to
>> figure out that 'xfer' needs to be run from the source back-end and not from a
>> front-end. (Maybe that is a feature request itself?) For some of the maintenance
>> utilities that check and modify the spools or config data, it's not always clear
>> if they can be run with the server live or if it should be shut down, such as
>> 'ctl_cyrusdb -r' or 'quota -f'.
> 
> Yeah, it would be fantastic if you can do some of these - particularly the ones
> that I don't use myself or understand particularly well.  Good docs are very
> important for a polished product :)

Yeah, another area should I should probably put-up or shut up ;)

>> 8. Last one, I promise: lmtpproxyd to use local mupdate instead of having to hit
>> the master. Maybe this has changed? I don't see it mentioned in the change log.
> 
> Don't have a clue sorry.
> 
> It would be fantastic if you could put these ideas on the wiki.  I'd be tempted
> to say "put items in Bugzilla", but honestly it's a bit of a jungle in there at
> the moment!  Maybe both, and cross link to the bug IDs from the wiki.

Sure, I can put them in both and perhaps expand on them a little more (use-cases
 for example). Thanks!

Wil

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20100114/049fb700/attachment.bin