Thanks for the feedback. I will try to put together a feature request for the pre-load script hook since that would address our key needs. We feed service definition data from many different sources such as Postman json and WSDL files, databases, csv files, etc... One problem is we constantly generate new service definitions and we want the current configuration passed to us so our configuration generating scripts can revise contact groups, determin if some other system already imported a service of the same name, etc... We already do this but it would be nice if there was a standard way to do it.
On Tue, Jan 12, 2016 at 10:54 AM, Michael Friedrich < [email protected]> wrote: > 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 >
_______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
