[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plans for the next release
From: |
Jan-Henrik Haukeland |
Subject: |
Re: Plans for the next release |
Date: |
01 Jul 2002 22:28:08 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) |
Martin Pala <address@hidden> writes:
> Maybe it will be useful to use similar categories as on (for example)
> http://developer.kde.org/development-versions/kde-3.0-features.html.
Probably
> I think it it will be useful to show the status
> (Planned/InProgress/Done) and maybe developer, that actualy tries to
> do it.
Agree. Lets see, is this right:
1. Configure monit from different sources; like LDAP. - Martin
2. Using monit as an init replacement - 2. Rory or hauk?
3. Implement dependencies between program entries - Rory
4. Add support for managing program groups in the web-interface - hauk
5. Extend the port check to understand URLs - Martin and hauk will help :)
6. Provide functionality for checking program CPU usage - hauk
> Maybe next hints:
>
> - rewrite parser of start/stop programs is needed (actualy it supports
> only following patterns:
>
> 1. program -x -y
> 2. program -x parametr
> 3. program parametr
Absolutely, this needs to be fixed. I'll look into it.
> - testing modules for LDAP and MySQL, etc. This maybe will require
> redesign the protocol module schema. It allows now only network
> oriented services to be monitored and the socket is opened before the
> module is called. It isn't possible to write service test module by
> using service API (as LDAP, MySQL, etc.), where the connection (and
> its resources -
> socket, etc.) is initialized under the controle of service library. It
> could be possible to use "low-level" programming instead of API
> functions, but i think that isn't the best way in that case. In the
> case that the monitored service uses for example unix-socket or
> something similar, it isn't possible to use present schema. I realy
> like the effectivity and simplicity of present schema, but maybe it is
> to closed for testing hundreds of services and protocols.
Maybe, but using sockets and sub-implementing a protocol is a lot
easier than to link in a thirdparty API. But I'm open for suggestions
to change the protocol implementation.
> - SSL support for monit httpd (as you mentioned in the past)
Yes, but I think that will have to be in a later version.
> - support for tcp-wrapper in monit httpd
I'm not sure what you mean, please explain
> I'm working currently on virtual host support for http testing
> module. I will also modify the protocol schema to be more general -
> support more types of testing modules and to allow to do some extended
> testing specific to protocol (such as URL request, etc.) I will
> prepare the LDAP testing module too, so it can demonstrate the argues
> why change is needed (i think). I hope that i will have it ready to
> the end of this week, so maybe we can then discuss the (draft) code :)
Great stuff.
--
Jan-Henrik Haukeland
Re: Plans for the next release, Martin Pala, 2002/07/01
Re: Plans for the next release, Jan-Henrik Haukeland, 2002/07/01