Is there any discussion on refactoring the scripting language within Icinga2? After trying to train a few people and migrate some Icinga1 configs I'm having mixed feelings about how it works now. Sorry in advanced if these things sound misinformed since I'm no expert on Icinga2. Nonetheless, these things are fresh on my mind and was hoping to get some feedback.
1) If the default installation did not use any scripting functions it would make it easier to learn out of the box. The scripting support could then be its own section in the docs instead of spread out. 2) It would be a more lean and stable core if the scripting support was an optional package (or at least it could be turned off). 3) Feature creap... i keep seeing new features like "if" statements to address common scenarios which forces me to revisit the docs after every upgrade. 4) Pre-load scripts via a hook. If it is not already possible, it would be nice to tell Icinga2 to run some pre-load scripts that are too complicated to be converted to Icinga2 native scripting... A simple version could have Icinga pass its config via json to the external script and use the resulting json as the configuration. 5) More modular runtime scripting. If the icinga scripting language was (if not already) a module with a standard interface, that would allow people to create adapters for the API allowing scripting in JavaScript, Python, etc... 6) Future options... if there is a JSON or javascript module, that would allow Icinga2 to easily change from a proprietary config format to JSON, YAML or whatever. I know some of these ideas at first glance may not seem feasible given sattelites and misc node synchronization but if the interfaces all worked out, the extra abstraction might make things more manageable? Icinga2 is already ahead of the game with dynamic configuration support and I appreciate the great opensource project.
_______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
