Feature #1187

Reinstalling of BP-Cronk and PNP-Cronk is necessary after web upgrade

Added by croft about 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:02/07/2011
Priority:HighDue date:
Assignee:jmosshammer% Done:

0%

Category:Installation
Target version:-

Description

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 :)

Associated revisions

Revision 3a38f14d
Added by jmosshammer about 3 years ago

  • Added additional siteconfig (#refs 1187)

History

#1 Updated by dnsmichi about 3 years ago

  • Status changed from New to Assigned
  • Assignee 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? :)

#2 Updated by jmosshammer about 3 years ago

  • Assignee changed from mhein to jmosshammer

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

#3 Updated by jmosshammer about 3 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 about 3 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.

thoughts?

#5 Updated by jmosshammer about 3 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

#6 Updated by jmosshammer almost 3 years ago

  • Target version changed from 1.4 to 1.5

In 1.5, reinstallation of pnp will unfortunately be necessary

#7 Updated by mhein almost 3 years ago

  • Target version deleted (1.5)

#8 Updated by jmosshammer over 2 years ago

  • Status changed from Assigned to Closed

Not anymore since 1.5

Also available in: Atom PDF