Reinstalling of BP-Cronk and PNP-Cronk is necessary after web upgrade
After Upgrading icinga-web with make upgrade the cronks for bp and pnp are gone...It would be more user-friendy, if you don't have to reinstall them after every upgrade :)
- Added additional siteconfig (#refs 1187)
#3 Updated by jmosshammer over 4 years ago
- 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 :)
#4 Updated by dnsmichi over 4 years ago
- 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
<!-- PNPColumn1 -->
<!-- PNPColumn1 -->
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.
#5 Updated by jmosshammer over 4 years ago
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