Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.icinga.com #13375] Append Groups in Templates #636

Open
icinga-migration opened this issue Nov 30, 2016 · 7 comments
Open

[dev.icinga.com #13375] Append Groups in Templates #636

icinga-migration opened this issue Nov 30, 2016 · 7 comments
Labels

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/13375

Created by leeclemens on 2016-11-30 22:43:11 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2017-01-04 12:54:41 +00:00 (in Redmine)


Append the groups array values, rather than re-assigning (similar to https://dev.icinga.com/issues/12941).

Use Case is having multiple Host Templates with Groups, only the group(s) assigned to the lowest level template are assigned to the Host object.

Attachments


Relations:

@icinga-migration
Copy link
Author

Updated by leeclemens on 2016-11-30 22:47:19 +00:00

  • File added 0001-Append-groups-array.patch

Github PR: #41

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-12-06 08:59:14 +00:00

  • Status changed from New to Assigned
  • Assigned to set to tgelf
  • Target Version set to 1.3.0

This introduces an incompatibility, but one I can happily live with. I guess there will then be requests asking for = and . Adding them to GUI and DB will be fun, but hey, we have to die one death or the other. And I prefer this one ;)

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-12-06 13:05:51 +00:00

  • Relates set to 12122

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-12-06 23:46:11 +00:00

  • Status changed from Assigned to New
  • Assigned to deleted tgelf
  • Target Version deleted 1.3.0

(Expected) problems appeared in the linked issue, seems this needs more discussion so far.

@icinga-migration
Copy link
Author

Updated by leeclemens on 2016-12-07 23:28:01 +00:00

Understandable, I read the feedback on github as well (using templates expecting to override all array values).

I can create a separate issue, but I also noticed unexpected behavior when using multiple Notification Templates. Say one had Up and one had Down. The result when imported would only have Down, for example. I was looking at the code for States and Types related to notifications and they seem to be handled differently. However, since they are similar to this overall array override/append discussion - I wanted to mention it here. In my use case I wanted to easily filter email vs page events. By filtering them by states/types I could avoid Ack or Downtime being paged out by importing the appropriate Notification templates when creating the User.

@icinga-migration
Copy link
Author

Updated by tobiasvdk on 2017-01-04 12:54:41 +00:00

I also ran into issue overriding the groups arrays. I suggest to add a boolean flag "override" which sets the group explicitly when enabled. Otherwise it would add the groups ("+=") from the template. Since mostly you will have multiple templates, e.g. "linux-server", "apache-server", ..., the default of "override" should be "false".

@thille-IM
Copy link

I ran into the problem too, when I used templates to add hosts to groups (and other things). The hosts were only added to the group(s) defined in the last imported template.

The solution mentioned by tobiasvdk, adding a boolean flag (checkbox) to decide wether to extend or replace an array is IMHO the best in terms of ease of use and probably easiest to implement.

sol1-matt added a commit to sol1-matt/icingaweb2-module-director that referenced this issue Aug 7, 2023
Add default value 'assign' for default group behaviour which matches group behaviour.
Add logic to IcingaObjectGroups so the class initalizes with the global group behaviour and sets the group operator based on the class operator.
Partial Fix for Icinga#344, Icinga#636, Icinga#824, Icinga#2273
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants