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 #13069] Allow to replicate console commands #4768

Closed
icinga-migration opened this issue Nov 8, 2016 · 2 comments
Closed

Comments

@icinga-migration
Copy link

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

Created by tgelf on 2016-11-08 10:53:57 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-11-08 10:53:57 +00:00 (in Redmine)

Backport?: Not yet backported
Include in Changelog: 1

User story

As a user I want to manage monitoring for a large amount of systems with Icinga 2 and Icinga Director while still being able to modify/add/remove hosts or services within a fraction of a second.

Requirements for Icinga 2

  • Provide a method __run_distributed_with_activation_context()
  • We might settle on an "official" method name later on, once this has proven to work fine
  • This method should behave like __run_with_activation_context (which works perfectly, but lacks replication)
  • This method must additionally require a second parameter specifying the target zone
  • This command should be sent as a fake file through our replication mechanism
  • Other nodes should parse and evaluate that snippet like any other replicated config file
  • These should be throwaway "config files", they should not be persisted at all

As an alternative it would also be pretty cool to add a 'zone' parameter to console/execute-script. Similar functionality might eventually be helpful for other tasks too.

Requirements for Icinga Director

Live creation has been implemented as an experimental feature quite some time ago and still works fine. We can however not really release this feature as long as it lacks replication support. In addition to what we have today, the following must be implemented:

  • A more flexible white-listing mechanisms. Currently only "create a new host" is hardcoded allowed to be executed immediately.
  • In future this should check all applied changed and validate whether a live modification is possible
  • Related objects like inherited or applied services, notifications and more should be deployed as single flat (fully resolved) objects

Relations:

@icinga-migration
Copy link
Author

Updated by tgelf on 2016-11-08 10:54:20 +00:00

  • Relates set to 13070

@icinga-migration icinga-migration added the enhancement New feature or request label Jan 17, 2017
@dnsmichi
Copy link
Contributor

The console cli command is for debugging purposes only. As such internal functions for activating objects are highly experimental and shouldn't be used in production environments. A proper design for runtime modifications is needed here, but not part of this issue.

@dnsmichi dnsmichi removed the enhancement New feature or request label Aug 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants