Current state

Adding plugins to an existing RHDH instance is a common usage.

However, currently, the process to deploy a new plugin includes the need to manipulate several config maps and possible secret.

Editing the dynamic configmap and the app-config cm requires careful care for maintaining the correctness of the content, while there is no validation for this process, other for watching for a successful or failed restart of RHDH.

In addition, removing a plugin follows the same pattern of manually editing resources.

When thinking of GitOps approach to manage RHDH resources, this experience isn't ideal.

—

There is currently no capability to declare dependencies between plugins. As a result, if a plugin relies on another plugin, any missing dependency is only identified at runtime. This can lead to situations where an RHDH instance is left non-functional (at least for the specific plugin) due to an uninstalled required plugin.

Proposal

By representing a dynamic plugin as a k8s resource, this process can be well-defined and simplifies. Having an API for the process (in the form of custom resource) will enable automating the process and implementing gitops approach for managing the RHDH instance.

Actions such as bumping plugin version, configuring the plugin, changing plugin's secret and more will be better defined and supported. This will enable reporting the result of plugin updates (in the CRs status).

—

A declarative approach to defining dependencies between plugins could help mitigate the dependencies issue.