Re: [Proposal] control storage systems

[Christian Hopp]

On 11 Oct 2002, Jan-Henrik Haukeland wrote:

> Martin Pala <address@hidden> writes:
>
> > > For the next major release (4.0?) we have 1) Central configuration
> > > (Martin)
> >
> > >
> > mea culpa - it was planned to 3.0, i hope i will now be more
> > accurate with the timeframe :)
>
> Well, you have some good excuses :)
>
> > > 2) Monitoring filesystems ++ (Rory + hauk)
> > >
> > +1
>
> Rory do not want monit to remove temporary files. I have no opinion
> this way or that, what do other committers think?

+1 for monitoring filesystems

-1 for removing, packing, moving of any files. Reason:  Data in /tmp
   or wherever could be in use and could cause damage to processes and
   in case some stuff is on NFS and NFS fails... bang!

> > > 3) Web-services (instead of SNMP)
> > >
> > +1   We maybe should implement similar mechanism as SNMP traps - it
> > means active notifycation in the case of failure. I'm not sure if we
> > should realy support SNMP traps as planned early - what do you think?
>
> I think that web-services could (probably) be used instead of
> SNMP. When it comes to push or pull, that is, if a monit server should
> push data to a central statistic/report gathering application or the
> central application should pull data from X monit servers I'm not
> sure. We have to think about this when we write up the design. The
> push model is maybe preferable since the central application can wait
> for incomming connection instead of knowing the address:socket for
> every monit servers to request data.

+1 for a HTTP based data pick up method, because the interface in
   monit is already existing.


> > > 4) Start work on a GTK or http/browser application for reporting status
> > >    (Should we do GTK or web for the client? Personally I would like
> > > to     play around a bit with GTK but web is probably easier)
> >
> > >
> > I personaly preffer web technologies for similar purposes such as PHP
> > for their portability and simple remote access
>
> Yepp, me too if I have to be honest about it it.

I prefer gtk+.  I have used it in python but a long time ago.  It was
nice.  It was just for testing.  But anyways I dislike any GUI
coding.  It's just not my domain.

+1 for a GTK client application... but a high tendency to 0 because I
don't see use then just publicity.

(...)

> > (or we can maybe use Zervlet as web alternative :)
>
> Yeah, that would be a good alternative. It's exactely for this type of
> applications I have written the Zervlet system. But the thing is, I
> partly plan to earn a living from the zervlet system and have thought
> long and hard about open source it and finally decided against it.
> It's going to be free for non-commercial use, but unfortunately not
> open source. I have no problem about using the zervlet system with
> monit, in fact I would love to do so, but I'm not sure about others?

We should not have any license trouble.  Maybe you have no problem
with it and maybe all the commiters.  But there are so many "license
lawyers" out there.  So we should better go with out Zervlet.

(...)

Christian

-- 
Christian Hopp                                email: address@hidden
Institut für Elektrische Informationstechnik             fon: +49-5323-72-2113
Technische Universität Clausthal                         fax: +49-5323-72-3197
  pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/chopp.key.asc  (2001-11-22)