Hi, > On 11 Jan 2016, at 16:47, Paul C <[email protected]> wrote: > > 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.
No worries. It is always hard to change, coming from the “old” world with some “simple” key value pairs on objects to a more modern somewhat dynamic configuration language. I guess it is easier to start “fresh” rather than migrating from different strategies in the past. After all, Icinga 2 is 1,5 years old with its first stable release on 16.6.2014 - and we changed quite a few configuration methods and strategies before releasing 2.0 … the first Icinga 2 commits happened somewhere in March 2012, and you might see that change from older blog posts targeting the pre-releases 0.0.x. What we have now is something more mature and stable than it was before. > > 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). Icinga 2 is a configuration DSL on its own, there is no “scripting support” in it. So you cannot just “turn it 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. That’s fairly normal when development of new features requires configuration changes or even new ideas generate new DSL keywords. It is nothing you’d generally want for 2.0+ making it feature-complete, but the reality in modern software development shows and proves different. Revisiting the documentation on upgrade is a good practice anyways. So you’ll learn about new features instead of trying to adopt examples found on the net, or never reading about it and not having a chance to evolve. You might feel bad about it, but hey, after looking into cool new stuff you’re normally excited to learn about it. And if not, just ignore it. All-in-all these language additions were implemented with upgrade safety in mind. If you do not need for example conditional statements, do not use them. If you prefer to solve a problem more elegantly, come back to a new version and check its new features. Or certainly ask on the community channels how others do solve it. Neither configuration nor programming scripts are 100% perfect and can always be improved in many ways. Unless the Changelog explicitly adds a breaking change your existing configuration is always safe to use on upgrade. No-one will accept software changing its configuration language on every major release, or changing the way (openldap 2.4 is my personal “headbanger”). > 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. That would require read/write/etc language additions allowing you to load an external file and decode the json object. Not sure if that’s wanted or needed currently. Users tend to solve such “conversion” issues with their own tool stack being familiar with it. Though if you provide a detailed feature request on dev.icinga.org we can sure think about it and discuss implementation scenarios. > 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… Not sure if I can follow here - can you give an example? > 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. Icinga 2 should (and imho must) only have *one* configuration DSL, and not multiple different ones. There’s only one way to do it right. “proprietary” is also not the correct term imho - the configuration language is documented in all of its details. I’m fairly certain users don’t want to learn yet another configuration language different to the one already existing. Apart from that I highly doubt that JSON or YAML provide the language features Icinga 2 already has implemented - they define a format, but don’t really compare to Icinga 2’s DSL. > > 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? Looking at other tools and their integration APIs it sounds more reasonable to focus on a clear-cut configuration language, helped with a REST API and configuration management tools such as Puppet, Ansible, Chef, etc … or the Icinga Director. Though there is always room to enhance the language features themselves, e.g. object accessor functions have been implemented in order to help resolve the old “on-demand macros” in more convenient way. So, given the topic with “refactoring icinga 2 configuration language”, I would say, that’s not gonna happen. We’ll instead enhance it in smaller steps, ensuring software and interface stability. Kind regards, Michael > 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 -- Michael Friedrich, DI (FH) Senior Developer NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg Tel: +49 911 92885-0 | Fax: +49 911 92885-77 CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461 http://www.netways.de | [email protected] ** OSDC 2016 - April - netways.de/osdc ** ** OSBConf 2016 - September - osbconf.org ** _______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
