[Kolab-devel] Extending Kolab

[Gunnar Wrobel]

"Alain Spineux" <aspineux at gmail.com> writes:

> On Mon, Jun 16, 2008 at 3:13 PM, Bernhard Reiter <bernhard at intevation.de> wrote:
>> 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.
>>
>>> 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.
>> You have a point in that kolabconf might not work well with _all_ potential
>> server packages, as more "specific" routines might be necessary.
>
> Maybe having a completely custom kolabconf for each platform is
> cheaper than trying to do the same with a smarter tools.
> Maybe make kolabconf itself more modular is a solution.
> The question is where to write the rules:  in kolabconf or in puppet ?
>
>>
>> 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.
>
> When people are experiencing some problem with a native version,
>  the first thing we to is to try the openpkg version!
>
> What is the advantage of a native version ?
> - performance ? (I'm jooking :-)
> - easiness ?  apt-get vs a rsync and a install-kolab.sh, not convinced
> - installation time ? We could provide binary vesion of openpkg
> package for each supported platform (can we ?)
> - others ?

The main point is stability. The Kolab2/OpenPKG is the most tested
version and thus the most reliable one out there. This will also
always remain this way and can be guaranteed by the very nature of the
OpenPKG distribution. The current stability in the Kolab2/OpenPKG
server is simply based on its inflexibility. By disallowing the user
choice it is possible to get the groupware server stable for most
users.

Stuff like puppet would also not change anything about this though I
guess this is exactly what Bernhard fears ;) It would simply loosen up
the inflexibility while still allowing the same stability.

Cheers,

Gunnar

>
>>
>>> 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.
>> 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
>>
>
>
>
> -- 
> Alain Spineux
> aspineux gmail com
> May the sources be with you
>
> _______________________________________________
> 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 <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~