Re: [Proposal] control storage systems

[Martin Pala]

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 removing files. I think it is sufficient to sent alarm. In the 
case that the space will come critical, it often signals some problem, 
that can't be solved just by removing temporary files. If the 
"watermark" is set carefully and the admin will be noted by monit about 
it, he can get action before something bad will happen. If the systems 
behavior is production of unneeded temporary files, it can be solved by 
simple cronjob.

>  
>
> > > 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.
Base is i think to pull data from monit daemon via present http layer 
(extended by mentioned methods) - the connection is initiated by data 
gathering/process mangling station. The note about SNMP traps is 
motivated to have some mechanism for sending actively trap/signal that 
some important event occured instead of waiting for connection from 
monitoring station. This is often used for example to signalize critical 
HW/SW problem - so if there could be daemon/receiver that can watch such 
traps and signalize alerts like SNMP does. Maybe there could be two 
phases - first that just collect data and manipulate monit nodes 
(client) and the optionaly second, where listener will be implemented to 
support behavior similar to SNMP traps (the first phase is more 
important, but the second will probably be easy to implement too).

>  
>
> > > 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.
>
>  
>
> > - on the other side, X application can be preffered on lot of the
> > sites too. I planne to look on X applications in the near future too
> > (i preffer QT but it doesn't matter) so it can maybe be good
> > exercise 
> >    
>
> I have done lots of GUI with Java before (hated it) and as you say it
> could be a nice excuse to try to write a GTK+ application. I prefer
> GTK above QT since I do not know squat about C++ and do not plan to
> learn it either :)
+1 for GTK

>  
>
> > (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?
>  
I don't have problem to write free aplication for commercial/closed 
zervlet library - i like monit 'cervlet' concept and it makes me fun to 
use it. If the zervlet library will be free of charge for non-commercial 
use (campus, etc.), i don't see any problem. Big firms can have profit 
from it (such as my employer :) so why they can't pay for the superior 
engine, that can be used for other applications too (i don't know 
license condition yet so maybe in fact it can be other way). I personaly 
planne to use zervlet library for future development, but there other 
opinions too - we can maybe start with GTK based application to 'join 
forces' and have completly opensource solution without care about 
lawyers as noted Christian.

> Anyway, I'll summarize this discussion for the 4.0 release after we
> have discussed it more and voted on it, and put it up on the monit
> web-site.
>
>