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 201 forks source link

Modify action link not shown if non default package name is used #1530

Open friesoft opened 6 years ago

friesoft commented 6 years ago

Expected Behavior

Modify action link on hosts and services should also be shown in case of non default package name (not "director") Using two director databases, one with the default package name and the other one with a custom.

Current Behavior

Modify Action link only shows for hosts/services using the "director" package name.

Steps to Reproduce (for bugs)

Use a non standard "Icinga package name" (/icingaweb2/director/config/settings) and deploy your config. The action link doesn't show up.

Your Environment

friesoft commented 6 years ago

Hm.. it somehow seems to be the other way round (looks like I mixed it up). The host using the non standard package name shows the modify action link.

If director is currently switched to the other database with the default packagename I get the following error on clicking the link: Failed to load icinga_host "host"

Is this a separate bug? My expectation would be if my user has the permission for all director databases it should use the appropriate one. But the object would have to know which database it came from to generate an appropriate link switching director to this database..

Thomas-Gelf commented 6 years ago

Yep, this is a bug. This change was pretty intrusive and there are still some related issues I have to deal with :laughing:

Thomas-Gelf commented 6 years ago

@friesoft: I have to postpone this, sorry. Checking every Director DB when showing a single service in the monitoring module is not an option. I have currently 20-30 of them, but even with less DBs it would be too fragile and slow.

We have a change in the pipeline that will replace the current Job Daemon with generic daemon taking care of more background jobs. It will handle migrations, pre-render configs, of course deal with our Jobs - and it will know about all your instances and their current health. So this will then be one call to that daemon to ask for the DB fitting the given package, and then a single call to the correct DB to look it up.

I'll not risk to break 1.5 with this change, that's why I have to postpone this.

Thomas-Gelf commented 4 years ago

v1.7 will now ship the background daemon I mentioned, immediately after the release we can start to work on such features.