[Kolab-devel] Extending Kolab
Gunnar Wrobel
wrobel at pardus.de
Tue Jun 17 21:41:14 CEST 2008
Bernhard Reiter <bernhard at intevation.de> writes:
> Gunnar,
>
> thanks for elaborating on the arguments.
> And sorry for the break, the tradeshow in Berlin had come with a massive
> workload and also Server 2.2.0 needs to be out.
>
> Am Freitag, 23. Mai 2008 11:34:10 schrieb Gunnar Wrobel:
>> Puppet provides all that in a clean fashion. None of the hacks
>> described above would be necessary. In addition puppet would enable us
>> to do a lot in the area of extensions.
>
> I am not still convinced yet, as you write below,
> there will be host system dependent changes,
> which are hacks just like the current changes.
What I was referring to were changes of paths. Stuff like OpenPKG
installing the imap spool in /var/imapd/spool and Gentoo in
/var/spool/imapd. So basically the same what we use the current
dist_conf stuff for. Calling that a "hack" would be a little bit too
much.
>
>> Richard is running Kolab on Suse. One day he is searching for
>> monitoring tools, finds munin and starts configuring it for his Kolab
>> server. He establishes it as a small puppet module. Once he is done,
>> he uploads the module to a central repository.
>>
>> Gunnar, running Kolab on Gentoo, sees the new module, also requires a
>> monitoring tool for his Kolab, downloads the module, runs it (maybe
>> fixes a few Gentoo specific things), resubmits to the repository.
>
> A "few Gentoo" specific things are just what we have been doing
> with kolabconf. Puppet looks large, so finding out what is actually happening
> will be more complicated than with kolabconf, as it is simpler and it works.
"it works" was the point I disagreed with.
> You have a point in that kolabconf might not work well with _all_ potential
> server packages, as more "specific" routines might be necessary.
Not only that. But I think the list was long enough in my last post
and it does not help to reiterate it.
>
> The choice of versions also bears a risk, people using Kolab Server usually
> get a quality tested system in this combination, any other combination of
> components has the chance the degrate the usage experience. Those problems
> with shape the "image" of Kolab Server with production users.
I don't see the connection between puppet and people suddenly being
able to choose package versions on Kolab2/OpenPKG. It wouldn't make
sense for the Kolab2/OpenPKG server, would it?
>
>> After several months of testing the module is also made available for
>> the Kolab server on OpenPKG.
>>
>> This is possible with puppet right here, right now.
>
> I do not believe that kolabconf currently is a large burden for Kolab Server
> nor would it help market uptake a lot, so for me this is not high on the list.
Well, I'll come back once the stuff has been completed for
Kolab2/Gentoo. :)
For people curios about how a Kolab configuration could look like with
puppet:
http://github.com/wrobel/pardalys/tree/master
Cheers,
Gunnar
> Bernhard
> --
> Managing Director - Owner: www.intevation.net (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
--
______ http://kdab.com _______________ http://kolab-konsortium.com _
p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de Dr. Gunnar Wrobel
Tel. : +49 700 6245 0000 Bundesstrasse 29
Fax : +49 721 1513 52322 D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Mail at ease - Rent a kolab groupware server at p at rdus <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the devel
mailing list