Feature #37530

Updated by Ernesto Puerta 9 months ago

h3. Description

* 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.

h3. User Stories

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.

h3. References

* "Feature Toggles by Martin Fowler":

h3. Implementation tips

* Ceph-mgr "config options": provide an easy (CLI) a way to set/unset settings. disable features.
* Options names can describe component hierarchies: @RBD@ enables/disables @RBD_IMAGES@, @RBD_MIRRORING@, @RBD_ISCSI@.
* For a front-end only feature toggle, there's a "PR ongoing": providing a @SettingsService@ for accessing Ceph-Mgr Config Options.
* For a back-end support, it should be easy to extend the @ApiController@/@RESTController@ for enabling/disabling them.