[dev.icinga.com #451] configuration check does not respect service_description not being set #224
Comments
Updated by mfriedrich on 2010-05-27 10:58:23 +00:00
|
Updated by mfriedrich on 2010-06-02 21:09:15 +00:00
|
Updated by mfriedrich on 2010-06-16 14:55:52 +00:00
this is not yet fully done - the hack checks directly on parsed service definitions. what if someone wants to set the service_description in a template? in our setup this is true for several service checks where service_decription is being defined in a seperated service template. Without this patch it works as expected, but with the patch, it bails out because the final check is in the wrong place. a finally compiled service object with all template inheritance resolved should be checked against a service_description. int xodtemplate_resolve_service(xodtemplate_service *this_service) in there, first the service definition and then recursive called, all template definitions are resolved.
at first, another condition would make sense, if both are false, set the having also to false.
after looping through all templates, check if having is false - if yes, then bail out with an error, the one we will remove from the old commit. |
Updated by mfriedrich on 2010-06-22 14:40:10 +00:00 hm i think i found an appropriate solution to be more compatible. currently with the previous bugfix applied, the verifyconfig bails out if service_description is missing in the service definition. since it could happen that the service object gets this directive from a template, we need to check after the object has been compiled together, but before it is not handled for the skipist search because of missing service_description. in fact, it should not create an error, just a warning on the object reading then. the preflight checks warning won't be affected in this stage, just if you run -v you will see what's missing using the current bugfix. |
Updated by mfriedrich on 2010-06-22 16:36:32 +00:00 ok solution was bullshit, a lot of warnings on templates where not service_description was defined - they are still service objects - were thrown. so another attempt - we know that services without host_name or service_description won't be registered during resolving them as objects, and adding to skiplist for checking duplicate hosts. after the adding to skiplist they are being registered and added as new services - but not if in precached mode (which needs 1x configuration generation of course!). so this attempt takes the if service_description==NULL => continue and wraps that into an error message, returning an error. At this stage all service objects already have their template inherits resolved. Test: service without description => FAIL service with description => OK service without description => OK service with description => OK (should be a warning for duplicate definitions though, but that's another bug) |
Updated by mfriedrich on 2010-06-22 16:36:46 +00:00
|
Updated by mfriedrich on 2010-06-26 13:54:55 +00:00
|
Updated by mfriedrich on 2010-06-26 13:59:11 +00:00
|
This issue has been migrated from Redmine: https://dev.icinga.com/issues/451
Created by marcel on 2010-05-20 13:45:55 +00:00
Assignee: mfriedrich
Status: Resolved (closed on 2010-06-26 13:54:55 +00:00)
Target Version: 1.0.2
Last Update: 2010-06-26 13:59:11 +00:00 (in Redmine)
I am not sure whether this is a bug or a feature, however if service_description is not set in service definition icinga runs, however ignores the whole service definition - this would be fine, although the
v check command says that the host does not have service assigned, which is not entirely truethe service is just wrongly set-up since service_description is a required refinition for serviceChangesets
2010-05-27 10:56:35 +00:00 by (unknown) ecffcf0
2010-06-23 06:07:26 +00:00 by mfriedrich 87f90d4
The text was updated successfully, but these errors were encountered: