Module Lifecycle

This document spring from https://shibboleth.atlassian.net/browse/IDP-2160 during which is became clear that the lifecycle of modules, particularly plugin-supplied is quite subtle.

During IdP Install and Update

• We only do things with modules list in the NEW IdP Installation

  • In particular plugin generated modules are not touched (enabled or disabled)

  • We only look at the currently installed plugins to make sure they support the new version

• Any ‘core’ modules are not enabled in the old install are installed early on during the install/upgrade

  • The core modules are currently idp.Core,idp.EditWebApp and idp.CommandLine

• At a later stage all the modules (found in the NEW installation source) which were enabled (in the being-updated distribution) are re-enabled.

• The old install’s concept of what modules exist is not looked at at any time

Plugin Install/Update/Remove

This is more complicated - we look at both the existing plugin version’s (if there is one) idea about modules as well as the new one.

Plugin Install

All modules in the getEnableOnInstall list (of the new plugin) are enabled.

Plugin Update

1. We get a list of all currently enabled modules from the existing install.

2. We call the new plugin at getEnableOnInstall to get a list of what modules to install

   • Then we enable, or re-enable them

3. At a later stage we ask the new plugin about modules it supports

   1. And if it was initially enabled (captured at stage 1) but not enabled in stage 2 we re-enable them

Plugin Uninstall

The plugin is consulted at getDisableOnRemoval and those modules are disabled.

Note: modules which are parented by this plugin but are not on the getDisableOnRemoval list, are not disabled.

• This implies that modules enabled by a plugin, or by its antecedents will remain “enabled” after the plugin has been uninstalled unless it is explicitly list by GetDisableOnRemoval

• This is where we came in with https://shibboleth.atlassian.net/browse/IDP-2160