The current whitelist implementation suffers from the following drawbacks:
- It introduces a runtime dependency on an external URL resource for configuration
- The whitelist is shared across all deployments (while there is some limitation due to filesystem-level permissions, if files are scoped differently or the mounts are too permissive, then exposes more files than necessary)
- The whitelist can't be changed for testing (indeed the current whitelist already contains test entries)
Currently hyperion which has its own config server system test container deployment, cannot pass the system tests because not all the tests use the same configuration file settings, yet all tests must share the same config files.
In addition, the benefit of i03 having a separate config server is somewhat negated by having a dependency on shared configuration held outside the beamline.
Acceptance Criteria
- Whitelists can be deployed as part of the application configuration instead of being fetched remotely.
The current whitelist implementation suffers from the following drawbacks:
Currently hyperion which has its own config server system test container deployment, cannot pass the system tests because not all the tests use the same configuration file settings, yet all tests must share the same config files.
In addition, the benefit of i03 having a separate config server is somewhat negated by having a dependency on shared configuration held outside the beamline.
Acceptance Criteria