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 #9218] Use the command_endpoint name as check_source value if defined #2985

Closed
icinga-migration opened this issue May 4, 2015 · 10 comments
Labels
blocker Blocks a release or needs immediate attention enhancement New feature or request
Milestone

Comments

@icinga-migration
Copy link

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

Created by bsheqa on 2015-05-04 07:40:56 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2015-09-05 13:19:28 +00:00)
Target Version: 2.3.10
Last Update: 2015-09-05 13:37:27 +00:00 (in Redmine)

Backport?: Already backported
Include in Changelog: 1

When using an apply rule for a service with a specified command_endpoint, this endpoint should be stored in the check_source column in IDO. Currently this is not the case, this leads to confusion when looking up the host where the command was executed. Icingaweb2 uses check_source to display this information.

Attachments

Changesets

2015-09-05 13:18:10 +00:00 by mfriedrich 3403765

Use the command_endpoint name as check_source value if defined

fixes #9218

2015-09-05 13:35:38 +00:00 by mfriedrich ae647dd

Use the command_endpoint name as check_source value if defined

fixes #9218
@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-05-04 13:58:52 +00:00

  • Status changed from New to Rejected

As far as the Icinga cluster is concerned the check was run on the instance which initiated the check. This is not a bug.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-06-15 06:04:06 +00:00

  • Status changed from Rejected to New

Re-opened as per the user's request.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-07-02 18:41:01 +00:00

  • Target Version set to Backlog

@icinga-migration
Copy link
Author

Updated by berk on 2015-07-28 14:52:10 +00:00

Hi,

we had the same situation here at the customer and the check_source should be the "command-executor"..

Best

Bernd

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-08-06 08:17:24 +00:00

  • Category changed from DB IDO to libicinga
  • Status changed from New to Assigned
  • Assigned to set to mfriedrich

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-08-27 16:13:55 +00:00

  • Priority changed from Normal to High

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-09-05 13:16:49 +00:00

  • File added icinga2_command_endpoint_checksource.png
  • Target Version changed from Backlog to 2.4.0

I've been testing a fix in my local 3 node cluster for a while which overrides the check source if a command_endpoint was set (only on the instance actually starting the execution). Using the Icinga 2 API helps perfectly to directly see the check_source :-)

icinga2_command_endpoint_checksource.png

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-09-05 13:17:50 +00:00

  • Subject changed from 'check_source' column should include the value of 'command_endpoint' to Use the command_endpoint name as check_source value if defined

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-09-05 13:19:29 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 0 to 100

Applied in changeset 3403765.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-09-05 13:37:27 +00:00

  • Target Version changed from 2.4.0 to 2.3.10
  • Backport? changed from TBD to Yes

@icinga-migration icinga-migration added blocker Blocks a release or needs immediate attention enhancement New feature or request libicinga labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.3.10 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocker Blocks a release or needs immediate attention enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant