Contribute to the DSpace Development Fund
The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.
| Title (Goal) | Admin UI - Database Driven Configuration Property Management |
|---|---|
| Primary Actor | System | Human |
| Scope | |
| Level | |
| Story (A paragraph or two describing what happens) | Repository Managers should be able to manage most configuration properties from an Administrative UI in DSpace. At this time management of configuration requires editing of properties files and restart of DSpace. Dependency Injection and Plugin Management should not be property based, instead existing popular Plugin or Dependency Injection approaches should be leveraged. |
Overview
Content Tools
All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license
, unless otherwise noted.
5 Comments
Terrence W Brady
Ideally, I would like the ability to deploy some configuration changes without needing to restart the service. I am not certain that these properties need to move into the database if there is a mechanism to force a property file to be re-read.
Tim Donohue
Moving this use case as "child" of Admin UI - Configurations in the admin UI, as it's one possible implementation of this broader use case. The broader use case has slightly more details of additional configs that likely should be added to the Admin UI control.
While Database Driven Configuration is definitely worth considering, we also may wish to determine whether the database is the best place for all such configurations, or if there are other ways they could also be either dynamically changed or re-deployed. So, this is just one possible implementation of how configurations could be managed from the Admin UI.
Tim Donohue
Should we decide to move to Database Driven Configuration, we would need to find a way to easily "sync" configurations across Test and Production instances of DSpace.
I has been pointed out (to me) that the detriment to moving configurations to the database, is that it could become more difficult to have a Test Server which "mirrors" your Production Server setup (simply because you'd be forced to "sync" the database-stored configurations, or manually apply the same configurations to each server individually).
While file-based configs are definitely not ideal, they are easy to "sync" across servers (simply via 'rsync' or 'scp'). So, in moving configurations to the Admin UI, we'd want to keep in mind a way to "sync" configurations across servers. If configs are stored in the database, this might still be achievable by simply allowing for a mechanism to:
We may want to have a way to dump/reload configs from a file for other use cases anyways (e.g. simply backing up just your configurations, in case something gets misconfigured and you'd like to "rollback").
Terrence W Brady
I agree that some synchronization will need to take place. The metadata and format registries may serve as a model for this. The master instance resides in the database, but the configuration can also be captured in code.
The configuration changes that I would most like to apply dynamically are handle-based changes such as themes & facets.
We often wish to develop a custom theme or facet in TEST using a TEST collection handle.
Ideally, I would then like to deploy this change to a PROD server, create a new collection in PROD, and then associate the custom change with that new collection handle.
Tim Donohue
+1 to the idea of the Metadata/Format registries serving as a model for this concept of syncing configs. It had completely slipped my mind that they do essentially achieve this idea of the "live" configs residing in the database, while they can be re-loaded/updated via importing an XML config file.