search

Icinga / icingaweb2-module-director

The Director aims to be your new favourite Icinga config deployment tool. Director is designed for those who want to automate their configuration deployment and those who want to grant their “point & click” users easy access to the configuration.
https://icinga.com/docs/director/latest
GNU General Public License v2.0
413 stars 203 forks source link

[dev.icinga.com #12294] Data types suggested from CheckCommands arguments might conflict #388

Open icinga-migration opened 8 years ago

icinga-migration commented 8 years ago

This issue has been migrated from Redmine: https://dev.icinga.com/issues/12294

Created by TheFlyingCorpse on 2016-08-02 18:31:04 +00:00

Assignee: (none) Status: New Target Version: (none) Last Update: 2016-08-26 14:03:09 +00:00 (in Redmine)

Data types suggested based on the arguments of CheckCommands might have conflicts and not the same use. Would it be possible to instance a data type to a given command, or what would you suggest as a way to fix this?

Is it trivial to create related types that can be used in its place? Say a new data type that is used in place of the original. For now I seem unable to change captions / set alternative descriptions. The "only" issue in this case is if is the data types differ or the description is not the same / alternative uses of the fields themselves.

Example of existing [conflict]()

icinga-migration commented 8 years ago

Updated by tgelf on 2016-08-26 14:03:09 +00:00

They should be overridden. Works for inheritance but doesn't when "inheriting" fields from commands. My intention was to explicitly allow to create such "conflicts" in a way that one might offer "location" as a free-text field on some hosts and as a dropdown once you mix in another template. Just, it currently doesn't treat fields inherited from commands the same way.