[naemon-dev] Ideas about future features

[Daniel Wittenberg]

On Dec 27, 2013, at 2:40 PM, Matthias Eble <psychotrahe at gmail.com> wrote:

> Hi Dan,
> 
>> This is the direction I am going (if I understand you correctly), in that a REST API will
>> be the only entry point in/out of the server, and will just take commands like addHost,
>> updateHost, updateService, etc.
>> 
> 
> Well, the question is, how the core will evolve. Will this be a core
> feature or just a broker module
> using dynamic object creation?

What I’m using is livestatus and the new QH interface, and probably some enhancements to QH for  more data.

>> I think the current flat config file syntax is too old and not flexible enough.  I would love to be
>> able to do things like define new types, why only host and services, why not just call them
>> whatever you want, like I want to define “applications” and assign whatever properties I want to them.
> 
> hmm. How would that possible? Hosts and services are quite different
> when it comes to scheduling:
>   * trigger host check if service check fails
>   * trigger service checks when host goes down
> 
> Wouldn't custom types require custom code to be executed in the core?

Well, sort of.  Right now we define the rules on how hosts and services react.  Why not abstract those rules out to configs that can be updated so that you can define the rules for any new types you want?

> It would be a shame if there would be a naemon core that relies on a
> 3rd party  config generator/importer which does not exist.
> I mean, there are some FLOSS projects that have a perfect core but,
> for example, only have half-baked front-ends because nobody
> volunteers.
> 
> But I guess that there will always be a version that can be run stand-alone?

Yeah, I would hope that we could always keep the core engine able to run on it’s own, so people like me that want to muck with it can do so without having to worry about the GUI or anything else if they don’t want to.  I can see it being a nice addition at some point if we could include a streamlined config tool like nconf or something so you can easily “yum install” and really get a full package of tools, like how Thruck is now integrated.

Dan