Hi all,

I just add some warning at the configuration check that warn the user if there are some unmanaged parameter in the configuration.

Here is the full list of the unmanaged parameters :

Warning : the folowing parameter(s) are not curently managed.
enable_predictive_service_dependency_checks
ocsp_timeout : O*HP commands are only useful for old distributed architecture, so if you use the Shinken one, it is no use for you.
host_perfdata_file_processing_interval
host_perfdata_file_template
log_archive_path
perfdata_timeout : Perfdata are manage by a broker module, not as a global parameter from now.
obsess_over_services
use_embedded_perl_implicitly
use_timezone
host_perfdata_file
use_syslog
ochp_timeout
obsess_over_hosts
use_large_installation_tweaks
service_perfdata_file_template
service_perfdata_file
use_regexp_matching :  if you go some host or service definition like prod*, it will surely failed from now, sorry.
service_perfdata_file_mode
service_perfdata_file_processing_command
use_true_regexp_matching
enable_embedded_perl : It will surely never managed, but it should not be useful with poller performances.
host_perfdata_file_mode
host_perfdata_command
ocsp_command
enable_predictive_host_dependency_checks
ochp_command
service_perfdata_file_processing_interval
host_perfdata_file_processing_command
passive_host_checks_are_soft
service_perfdata_command
additional_freshness_latency
date_format
translate_passive_host_checks
auto_rescheduling_interval
soft_state_dependencies
illegal_object_name_chars
auto_reschedule_checks
auto_rescheduling_window
enable_environment_macros : Please check at your plugins if they are using it. Only few of them are using this feature.
illegal_macro_output_chars



We've got some family pack here :

*O*HP commands :
ocsp_timeout : O*HP commands are only useful for old distributed architecture, so if you use the Shinken one, it is no use for you.
ocsp_command
ochp_command
obsess_over_services
ochp_timeout
obsess_over_hosts
I think this one are not useful with our architecture because the only thing I see for using them is the nagios HA way. I don't think it's so useful to manage in fact. If the use got such an installation, migrating to the new one will be quite easy for him. I'm not for managing them in 0.4 (maybe later if someone really need them or propose a patch for it).



Perf data related one :
perfdata_timeout : Perfdata are manage by a broker module, not as a global parameter from now.
host_perfdata_file_processing_interval
host_perfdata_file_template
service_perfdata_file_template
service_perfdata_file
host_perfdata_file
service_perfdata_file_mode
service_perfdata_file_processing_command
host_perfdata_file_mode
host_perfdata_command
service_perfdata_file_processing_interval
host_perfdata_file_processing_command
service_perfdata_command
All of them are for the perfdata broker module. Not all options are managed from now, we should add them, even if somes are just terrible for performances (launch a script for each data...). Should be in 0.4.


Log ones:
log_archive_path
use_syslog
It's now a broker module that manage them. Syslog is not managed, and should be in it's own module (windows users do not care about it). So ok for managing it for 0.4.


Regexp and configuration ones:
use_regexp_matching :  if you go some host or service definition like prod*, it will surely failed from now, sorry.
use_true_regexp_matching
Even if the hostgroup &()|! matching it make less sense of using it, we should manage it. Let add it for 0.4.
illegal_object_name_chars
illegal_macro_output_chars


Macros:
enable_environment_macros : Please check at your plugins if they are using it. Only few of them are using this feature.
This one is a tricky one : nearly no plugins use them, but there are, so we must manage it even if it will raise the network usage. So ok for managing them in 0.4, but I'll like to set it to 0 in the default conf sample so every one will use the good way of passing parameters... And If I'm not wrong, livestatus users have to disable it, so it will disappear in the future I think.



Various ones:
use_large_installation_tweaks : simple fork and clean memory are no used. The only thing is the env_macros.
enable_predictive_service_dependency_checks : not a fan of this. It will make the scheduling code a mess for a very time won.
enable_predictive_host_dependency_checks
use_embedded_perl_implicitly : hum.... will not be easy this one :)
enable_embedded_perl : It will surely never managed, but it should not be useful with poller performances.
passive_host_checks_are_soft : any body can say me what is the real goal of this one?
use_timezone : quite good. But should also be managed in the hosts and satellites. first manage a easy global version for 0.4.
additional_freshness_latency : quite easy, will be in 0.4.
date_format : Where is the date printed? It's all in unix time if I'm not wrong.
translate_passive_host_checks : I never think this one was so useful.
auto_rescheduling_interval : it's a way to make the scheduling more smoothly. Why not, but not so important for a 0.4.
auto_reschedule_checks
auto_rescheduling_window
soft_state_dependencies : why not. Let manage it for 0.4


Features choice :
Are every one ok with theses choices of manage/unmanage for the 0.4? Remember that a 100% compatibility is not a good goal, and there are some parameters that are just unused too.

If it's ok, we can release the 0.3 as soon as we've got the new demo VM I'm (re)creating. The in-progress debug of status.dat can be done for the 0.4 version (it will have it's own release :) ).


Jean