Updated by mfriedrich on 2011-02-07 16:59:20 +00:00

• Status changed from New to Assigned
• Assigned to set to mhein
• Target Version set to 1.3

@marius

I think we talked about that once in a while - can you please have a look and report at tomorrows meeting? :)

Updated by jmosshammer on 2011-02-09 09:33:06 +00:00

• Assigned to changed from mhein to jmosshammer

Module specific changes will be written in *.sites.xml

Updated by jmosshammer on 2011-02-11 17:18:03 +00:00

• Status changed from Assigned to Closed

The BP Addon needn't to be reinstalled anymore with the new version. Modules should from now on only use sites.xml or the routing.modules.xml to be separated from "native" icinga logic.

Unfortunately, the pnp integration can't be handled that way, as it modifies the xml templates - perhaps we find a solution for that in the next release :)

Updated by mfriedrich on 2011-02-14 16:54:57 +00:00

• Status changed from Closed to Assigned
• Priority changed from Normal to High
• Target Version changed from 1.3 to 1.4

i want to keep track fo that for the next release, so re-opened.

i had an idea during the night on how to resolve that - if the pnp is integrated in the view, it's always a pattern that is being changed.

maybe we will do the following:

• change the default cronk and add a place holder like

into the existing Cronks (even if pnp is not integrated).

• the database gets a new table like cronks_modules or similar, which hold the information on the installed module (pnp in this case). this only needs to be a boolean value like TRUE:FALSE.

• if pnp is installed once, the db table entry is set to TRUE and the cronks are recreated (xmls are written)

• now if you upgrade icinga-web (meaning make upgrade is run), the script should check against the db table and if pnp integration is set. at the end, after icinga-web is upgraded, the pnp integration will be overwritten once more.

so maybe we don't need the place holders, but the db knowing about the pnp module and the upgrade script integrating that again will be mandatory.
i do think that this would be a good possibility to allow other cronk-rewriting modules to be easily integrated into icinga-web.

thoughts?

Updated by jmosshammer on 2011-04-14 07:05:15 +00:00

It would be good to have a universal solution for this, not only for pnp.

• Quick (and a little bit dirty) solution: We could add an 'update-hooks' folder that has pre and post installation scripts that modules simply put there. On update, simply all scripts with preupdate** are called, save the current config state and afterwards the postupdate** scripts are called to recreate the config afterwards.
• In the future (1.5) modules should not install themselves but icinga-web should install them and keep track of the changes. Then we could use some kind of 'install hooks' that will be called before and after an update and icinga-web would be able to recreate config changes

Updated by jmosshammer on 2011-04-30 10:22:41 +00:00

• Target Version changed from 1.4 to 1.5

In 1.5, reinstallation of pnp will unfortunately be necessary

Updated by mhein on 2011-05-17 12:38:46 +00:00

• Target Version deleted 1.5

Updated by jmosshammer on 2011-09-13 12:05:48 +00:00

• Status changed from Assigned to Closed

Not anymore since 1.5