Re: Proposal: change connection tests statement

[rory]

I agree with Martin. (-1)

> I though about it, i don't agree with these changes. Here is my -1 for
> both points, bellow are my arguments, but please don't take my vote as
> 'veto' (it is just my point of view ;)
>
> Jan-Henrik Haukeland wrote:
>
>>1)
>>
>>In the current monit version it is possible to write a connection test
>> in a process entry as shown below:
>>
>> check process xinetd with pidfile /var/run/xinetd.pid
>>       start program = "...."
>>       stop program = "..."
>>       alert address@hidden
>>-->    if failed port 631 then alert
>>
>>I suggest that this is removed in the next release and that a
>> connection test is only allowed in a check-host entry. As the example
>> below
>>illustrate the depend statement can be used to express the same thing.
>> There are 3 reasons I want to remove connection tests from a process
>> entry, a) Logically it does not belong in the process entry b) it's
>> easier in the documentation to explain connection test if it's in one
>> place c) the code will be better.
>>
>>Unless I get a veto vote on this I'm going to change the code when I
>> get time. Yes, it will break backward compatibility but it will also
>> make the control file language cleaner. We could deprecate connection
>> tests in a check process entry and allow it in a few new versions of
>> monit or invalidate now and print an error? Personally I would like to
>> invalidate it now with an explanatory error message.
>>
> I think we should keep the connection test support for local process. I
> think it is just one property of the process and it is correct to define
>  all its characteristics in one container. For example the other socket
> type (unix socket) is not possible to test via 'check host' statement,
> but logicaly addresses the same functionality of the process, which is
> requests handling (though via other transport channel).
>
>>
>>2)
>>
>>In addition I also propose that we change the connection statement and
>> remove host name from it. Since we have a check-host statement it is
>> redundant and it sort of breaks the logic of a check host entry in that
>> you can specify another host than the one checked. I.e. this is legal
>>
>> check host redhat with address www.redhat.com
>>    if failed host debian.org port 80 ...
>>    if failed port 80 ....
>>
>>In other words I suggest that it's not possible to specify the host in
>> the if-test and that the above is illegal. This means that if you want
>> to test another host you must create a new check host entry.
>>
>>
>>
> I think it is useful to have support for host sprecification in
> connection statement. The reason is that you can use 'check host'
> statement as test for remote process with virtual hosts support. For
> example:
>
> check host myhost with address 192.168.1.1
>   if failed host www.alias1.com port 80 ...
>   if failed host www.alias2.com port 80 ...
>
> The characteristics of both these virtual hosts are given by the same
> backend process => if you involve some "hard" action (such as restart)
> it will affect the other service as well. Because the service will most
> probably have the same state, there could be race condition. For these
> reasons i think that it is one subject for testing. The proposed syntax
> may brake the test to two parts, but the relationship here is broken
> (there's no dependency - it is the same object). The split syntax can
> complicate the control file too - some servers has hundreds of virtual
> hosts, in current syntax this means one check host statement - in new
> syntax this will require same number of check host statements as virtual
>  hosts.
>
>
> Martin
>
>
>
>
> --
> To unsubscribe:
> http://lists.nongnu.org/mailman/listinfo/monit-general