Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #471] don't clean live/config data on core startup (NEBTYPE_PROCESS_PRELAUNCH) #237

Closed
icinga-migration opened this issue Jun 2, 2010 · 1 comment

Comments

@icinga-migration
Copy link

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

Created by mfriedrich on 2010-06-02 15:15:04 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2010-06-02 21:10:04 +00:00)
Target Version: 1.0.2
Last Update: 2010-06-02 21:10:04 +00:00 (in Redmine)


basically speaking, it's not always clear what ido2db tries to do during startup.
especially the startup of the core, where the callbacks send all new and updated config data over to the database.

normally, if this state is being reached and the realtime data is too old (seconds), ido2db will try to clear all realtime and all config tables.
Furthermore there's a relationship between several config objects getting cleaned and the objects table, where all config objects are updated to is_active=0.

So, the question is how to prevent those cleanups and let the user decide what he really needs.
The decision, which config gets to ido2db, is done in idomod.cfg and the config_output_options.

But the decision being made for clearing the tables is just based on the core startup.

The proposed patch is to add 2 new config options, which are set default to 1, enabling the cleanup.

clean_realtime_tables_on_core_startup=1
clean_config_tables_on_core_startup=1

The user can then decide, which of those should be disabled (enabled is the default, also if those options are not set in older ido2db.cfg).

Changesets

2010-06-02 16:55:29 +00:00 by mfriedrich 6d0f795

idoutils: add config options to allow users decision on clearing realtime and config tables on Icinga core startup

Actual config objects are marked as (in)active, because
disabling the clearing results in historical config.

This feature was a users demand for keeping the
custom variables during Icinga restart, being more historical
and building own relationships on existing object_ids.

Existing and same config data will be updated, not added twice.

refs #469
refs #471

Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2010-06-02 21:10:04 +00:00

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant