[Kolab-devel] Extending Kolab

[Alain Spineux]

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 ?

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