d9b75c4a86
The director automatically removes uncollected deployments if they're older than the running one. Deployments are uncollected if Icinga 2 did not write a status file or startup log (yet). This happens when you manage to ship a deployment while Icinga 2 is already preparing to restart with a deployed configuration. It also removes deployments which were forgotten by Icinga 2 because of bugs in previous versions. If there are uncollected deployments, the check whether they are older than the running one is based on string comparison of the deployments' start time. While this works for MySQL and MariaDB where the output of timestamps is always ISO, it may fail for PostgreSQL because there the output format is configurable. If the output format is set to report the day first, the string comparison "fails" and removes every first deployment of a month: Deployment timestamp: 01-JUN-19 00:03:37 -07:00 Running timestamp: 31-MAY-19 23:54:53 -07:00 The string comparison now reports the deployment as older than the running one and removes it. The fix is as easy as to use timestamps for the comparison. |
||
|---|---|---|
| .github | ||
| application | ||
| contrib | ||
| doc | ||
| library | ||
| public | ||
| schema | ||
| test | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .travis.yml | ||
| LICENSE | ||
| README.md | ||
| configuration.php | ||
| module.info | ||
| phpcs.xml | ||
| phpunit.xml | ||
| run-php5.3.php | ||
| run.php | ||
README.md
Icinga Director
Icinga Director has been designed to make Icinga 2 configuration handling easy. It tries to target two main audiences:
- Users with the desire to completely automate their datacenter
- Sysops willing to grant their "point & click" users a lot of flexibility
What makes Icinga Director so special is the fact that it tries to target both of them at once.
Read more about Icinga Director in our Introduction section. Afterwards, you should be ready for getting started.
Documentation
Please have a look at our Installation instructions and our hints for how to apply Upgrades. We love automation and in case you also do so, the Automation chapter could be worth a read. When upgrading, you should also have a look at our Changelog.
You could be interested in understanding how the Director works internally. Working with agents is a topic that affects many Icinga administrators. Other interesting entry points might be Import and Synchronization, our CLI interface, the REST API and last but not least our FAQ.
A complete list of all our documentation can be found in the doc directory.
Contributing
Icinga Director is an Open Source project and lives from your contributions. No matter whether these are feature requests, issues, translations, documentation or code.
- Please check whether a related issue already exists on our Issue Tracker
- Make sure your code conforms to the PSR-2: Coding Style Guide
- Unit-Tests would be great
- Send a Pull Request (it will automatically be tested on Travis-CI)
- We try hard to keep our master always green:
Addons
The following are to be considered community-supported modules, as they are not supported by the Icinga Team. At least not yet. But please give them a try if they fit your needs. They are being used in productive environments:
- AWS - Amazon Web Services: provides an Import Source for Autoscaling Groups on AWS
- File-Shipper: allows Director to ship additional config files with manual config with its deployments
- PuppetDB: provides an Import Source dealing with your PuppetDB
- vSphere: VMware vSphere Import Source for Virtual Machines and Host Systems