2008/4/24 Sylvain Viollon <sylvain@...>:

> cut
> >
> > zc.buildout can be used for applications setups and is not plone/zope
> > centric.
> > For instance, our buildbot is a buildout.
> >
>
>   Yes I known that. But I found silly to install 10 same things on a
> computer then you need to have only one, even if it's easier. For
> instance, I found silly as well to install apache in your buildout,
> and not use the system one.




> You don't have anymore update and security
> update, unless you do it by yourself, and your setup have been check
> over other security issue which may happens due to it.
>

Who said so ? I am just talking about make it easier to configure
softwares, not recreate a system in your buildot.

In some case though, it is not silly at all to install some parts in a
buildout
For instance, buildbot is a simple egg, so an easy_install is simpler that
using
a system-wide installation.

But this is a topic that is currently discussed at python level, since
setuptools
will be the next distutils and since eggs where blessed by Guido.
This is a tough problem anyway, wheter the packages
upgrades are system package-centric or application-centric.

If all your customers are under debian or red-hat, it makes a lot of sense
to use
debs and rmps. But when you have some customers under windows, a
standardized
way to distribute your app is not obvious at all.

I'd be happy to talk about that at the sprint, to compare our distribution
models


>
>  But, pay attention, I don't see the advantages to *install it*, but
> you can still provides an configuration file to *run* apache if you
> want in your buildout (assuming you have only one application on your
> computer, which is 80% never the case).
>

Yes, exactly, and this is the same thing for monitoring needs imho


>
> > By having a buildout recipe that allows setting a monitor in a matter
> > of lines, let's say:
> >
> > [monitor]
> > recipe = collective.recipe.simplemonitor
> >
> > watch =
> >     8080 TCP mail ...
> >     8282 TCP
> >     ...
> >
> > ...
> >
> >
> > This can be used either in a zope buildout on servers that have only
> > one zope server,
> > either on a buildout dedicated to monitor several applications (and
> > to do other things maybe)
> >
>   If you make an buildout only for monitoring I agree, which monitor
> others buildout.
>

Whatever fits your need.


>  But what's the advantages over a existing system, which
> works, is tested in real condition (since more people use it), and where
> you can found a lot more *administrator* to manage it ? (Even if it's
> easy, people usually don't want to make effort to learn new stuff when
> they known a working way).
>

The big advantage is to automatically provide simple monitoring services
when
you deliver, let's say, a plone application. We have for instance a recipe
to set up a log rotation (rotatzlog)

The real blast is to be able to define monitoring in
a few configuration lines, and let the system install (or not) then
configure the damn
thing, no matter what the platform is.

I am not debating on what is the best solution, if you have a Nagios
administrator
available, fine, it would be dumb to provide such a thing, and not use his
work.

But if you deliver a application to a customer that don't even have an
administrator,
being able to provide such tools makes a lot of sense. If it works by
itself, on every platform,
without having to install a lot of third-party software, that's even better.


> >
> > >  Unless you have an application which really doesn't work, and here
> > > you can put a zopectl restart every hour in a crontab.
> >
> >
> > zopectl restart is not a solution imho, because when a zope server
> > drop, even if it is ok to restart
> > it, the problem that put it down should be corrected.
> >
> >
>
>   I agree on this point, but sometimes it's difficult to dig it, and
> it's the temporary solution (which can last years by the way).
>


Sure.

Anyways, we do need such a recipe for our needs ;) so maybe the sprint is
not the right
place to work on this, I don't know.. unless someone else feels he has the
same kinf of need.

Regards
Tarek



>
>  Sylvain,
>
>
> --
> Sylvain Viollon -- Infrae
> t +31 10 243 7051 -- http://infrae.com
> Hoevestraat 10 3033GC Rotterdam -- The Netherlands
>



-- 
Tarek Ziadé - Directeur Technique
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline - 1 rue Royale - Bâtiment D - 9ème étage
92210 Saint Cloud - France
Phone : 01.78.15.24.00 / Fax : 01 46 02 44 04
http://www.ingeniweb.com - une société du groupe Alter Way

Attachments

text.html (text/html) 6.5 kB