[Mageia-webteam] Initial hosting requirements for maintainers db

[Michael Scherer]

Le mardi 11 janvier 2011 à 23:07 +0000, Kosmas Chatzimichalis a écrit :
> The initial requirements for installing the maintainers db in the
> mageia server are:

Again I am sorry to be harsh and quite direct, but the requirements
seems rather "too much". 

I do not think it would be wise for us to host a full environment for
each application based on every coder preference, especially when taking
in account that our main product is a Linux distribution, ie basically a
environnement that serve as a base for running other softwares. 

So bypassing this seems rather odd. I would maybe do it for a business
critical complex application whose fate of my company depend on, but I
do not think this project belong on this category for the moment, nor
that it couldn't be fulfilled by what we offer in the distribution so
far.

> 1. RVM (Ruby version manager)

>From what I know, that would likely mean compiling our own ruby version
on the server, using its own separate set of gems. In term of work, it
would like adding a specific chroot, or a special vm of a different
distribution just to host the application. ( different distribution
since that would be totally unintegrated with the rest of the servers )

I am sorry to say that I do not really see this as a good idea, because
that put the burden of taking care of the environnement on sysadmin
(especially security wise), and totally bypass the collaboration system
that we have setup ( ie puppet + svn + integrated shared hosting ).

> 2. Rubygems (1.3.7)
> 3. Rails (3.0.3)

Again, I would rather use the package given by the distribution used on
the server ( ie a Mandriva 2010.1 for the moment, soon to be upgraded to
the first Mageia release ). This would mean for the moment rails 2.3.10
and ruby-RubyGems 1.3.5. 

A small minor backport would be of course ok ( ie for rubygems ), but a
full update of the rails stack is likely be more work, especially since
it would requires others updates ( like the various active-* parts ).

Moreover, using distribution rpm give everybody the same set of module
to work with, if the need to host/develop multiple rails applications
arise ( and I think we cannot exclude this possibility ) without having
to have 1 set of gems per application. And again, we will not need to
handle security ourself ( or at least, no need to do the hard work as
this is the goal of the security team ).

So far, we were perfectly able to do it for every perl web application
we wrote ( be it epoll, mga-mirrors, catdap ), and also for external
applications in python and perl ( sympa, bugzilla, transifex ). 

> 4. MySQL or PostgreSQL (if everything else is using it).

I would strongly support Postgresql, as we do have a server running, and
that everything is using it on the web server so far ( ie, the 5
database enabled application use it, and wiki should also ).

Given the fact that the maintainer db is basically a simple CRUD web
application, I doubt that this will change much for you as I do not
expect any advanced mysql features, except the old "autoincrement vs
trigger" trick. But I also hope that modern ORM used nowadays are able
to hide that sort of low level details.

Again, if there is no other way but to use mysql, we could, but I do not
think this is the case.

> 5. Passenger (Apache mod_rails)

As I told in my answer on the git topic, could we avoid using passenger,
and switch to fastcgi ?

Otherwise, the web server will likely suffer of bloat since each process
will bundle perl interpreter + modules (due to bugzilla installation
that requires mod_perl) and a ruby interpreter + modules. And I think we
should avoid this for performance reasons, since processes are reused
between each request by apache ( standard mpm-prefork,  as I am not sure
that everything will be thread safe ). 

We also use fastcgi to be able to finely tune application, by deciding
how much server should be started per web application. And so far, every
application we use are able to do it, except bugzilla who requires
mod_perl for the moment. 

I know that rails support it too, and we will take care of using static
mode to avoid the issue of slow startup of the server, problem which is
basically the same for catalyst, who is used on 3 of our applications
( epoll, catdap, mga-mirrors ) at the moment,  the same for django, used
for transifex .

-- 
Michael Scherer