mgr/dashboard: Feature toggles
- Provides support for disabling/enabling features from the Ceph-dashboard by means of configuration changes.
- In this context features should be primarily considered from UI perspective and include at least:
- Single components (e.g.: iSCSI)
- Optionally: Sets of related components (e.g: RBD comprising Images, Mirroring & iSCSI). This could also be enabled/disabled on a per-component basis.
- Takes precedence over Role Based Authorization: features are either enabled/disabled for all users.
- No need for an instant effect: a Ceph-mgr or module reload could happen if needed. However, no code changes or builds should be needed.
- No need to disable back-end functionality too.
Feature toggles bring in benefits for a lots of user personas:
- As a System Administrator I want to disable Ceph components I don't have deployed (e.g: iSCSI) so that the dashboard only reflects the relevant information and workflows.
- As a Ceph Distributor, I want to disable Ceph elements I don't support (e.g.: CephFS).
- As a Back-end Developer I want to disable a new experimental feature so that I don't break/interfere with other ongoing developments, or deployments.
- As a UI/UX Designer I want disable an improved feature so that I can run an A/B test to quickly gather feedback from the same build.
- Ceph-mgr config options provide an easy (CLI) way to set/unset settings.
- Options names can describe component hierarchies:
- For a front-end only feature toggle, there's a PR ongoing providing a
SettingsServicefor accessing Ceph-Mgr Config Options.
- For a back-end support, it should be easy to extend the
RESTControllerfor enabling/disabling them.
#1 Updated by Ernesto Puerta almost 4 years ago
Feedback from the F2F meeting:
Feature status indicators
- Features added to Ceph may not be supported by either SuSE or Redhat, so this discussion centers on how/if preview features should have some indicator in the UI to warn the admin.
- It's also important to ensure that if this path is adopted, each downstream vendor can select which features are viewed as not GA/supported
- Suse: support everything in the UI/CLI when it's shipped but no message is shown to indicate if something is Tech Preview
- Do we want to hide those elements?
- BlueStore, CephFS snapshots did have a warning that it was experimental - CLI emitted a warning
- "Allow experimental" setting to expose experimental features
- Do we similarly want to enable / disable other features (e.g. RGW, RBD, etc.)?
- Showing/hiding functionalities could be done via setting the user permission. The question is if the user permission can be applied to features that are declared as experimental
- If the permissions for a module are removed it means they are removed from the front-end and the REST API
- How granular would it be? E.g. a feature within RBD
- Extend and show experimental info in the About modal?