On Mon, Jul 21, 2014 at 09:12:17AM -0500, Endi Sukma Dewata wrote:
On 7/20/2014 9:13 PM, Fraser Tweedale wrote:
>With the introduction of LDAP-based profiles, the ProfileSubsystem
>needs access to the profile configuration. When spawning a new
>instance, the CMS tries to start its subsystems, but the
>ProfileSubsystem cannot start because it requires the LDAP
>connection details, which are not yet configured (this action is
>performed by SystemConfigService.configureDatabase).
>
>OK, so what to do? I see two options:
>
>1) Remove the profile subsystem from the initial CS.cfg, so that it
>doesn't start up. Add it back into CS.cfg as a configuration step;
>on the next startup, it will run and be happy, because the database
>configuration is there.
>
>2) Handle the absense of database configuration in ProfileSubsystem
>itself. That is, keep track of whether initialisation has been
>successfully performed, and try again "just-in-time" when it is
>needed. This probably violates semantics of the IProfileSubsystem
>API.
>
>Feedback or other ideas are appreciated. I'm going to push ahead
>with option (1). Both options feel like hacks but (2) seems like a
>worse hack ^_^
Agree with option 1, but instead of removing the profile subsystem from the
list we probably can also add something like an 'enabled' parameter.
The profile subsystem should be disabled by default, so it will be skipped
during initialization. After the configuration the profile can be enabled
and supplied with the proper database configuration.
Thanks Endi. Having the 'enabled' parameter was a very good idea -
it turned out to be much easier to implement than removing the
parameter (which broke the dynamic subsystem loading code).
Cheers,
Fraser
--
Endi S. Dewata