Feature Overview (aka. Goal Summary)

The context (problem statement):

1.

One of the problem of configuring instance (CR) scoped dynamic plugins is that it uses ConfigMap instead of direct CR configuration which makes configuration more complex (see also  https://issues.redhat.com/browse/RHIDP-3708), less visible and does not allow operator to perform earlier validation (of "known" fields) and fail faster when possible.

2.

Operator manages leveled configuration where profile contains defaut dynamic plugins configuration and is potentially able to replace container's dynamic-plugins.default.yaml file configuration. So, the responsibility of install-dynamic-plugins initContainer's Python script would be downloading/unpacking/saving according to incoming dynamic plugins configuration (as mounted file, no image changing).

The problem with current operator implementation is that it is not reasonable possible to merge default profile's configuration with configuration defined in config map referenced in spec.application.dynamicPluginsConfigMapName of Backstage CR as it would require modification of user defined config map.

3.

We have a "default dynamic plugins" configuration which is a good thing as it simplifies configuration of dynamic plugins for user. Adding 

includes:
  - dynamic-plugins.default.yaml 

user automatically enables all the default plugins and is able to enable defined but disabled by default plugins.

Since the dynamic-plugins.default.yaml file is located in the install-dynamic-plugins initContainer and so is pretty much invisible for user (putting its content to documentation is hardly reasonable as it is pretty big as contain all possible plugins and even though it is hard to read and recognise enabled and disabled plugins)

Since the dynamic-plugins.default.yaml file is a part of RHDH image, changing it is possible only with image rebuild (the problem we essentially try to solve introducing dynamic plugins).

In the other words default configuration of dynamic plugins is rather part of code than part of configuration.

Goals (aka. expected user outcomes)

Making dynamic plugins configuration in CR instead of reference to unstructured configMap making Backstage configuration experience more clear and adding possibility to validate and fail faster.

Requirements (aka. Acceptance Criteria):

• Implement addition to the Backstage CR spec:
  The spec.application.dynamicPlugins must contain:
  a `plugins` list of objects with the following properties:
  `package` the NPM package to install (either a package name or a path to a local package)
  `integrity` a string containing the integrity hash of the package (optional if package is local, as integrity check is not checked for local packages)
  `pluginConfig` an optional plugin-specific configuration fragment
  `disabled` an optional boolean to disable the plugin (`false` by default)
  an optional `includes` list of yaml files to include, each file containing a list of plugins.

• add the same test suite as for spec.application.dynamicPluginsConfigMapName
• deprecate spec.application.dynamicPluginsConfigMapName
• update upstream and downstream documentation

Out of Scope (Optional)

• modifying existed dynamic-plugins format
• changing install plugin script

Customer Considerations (Optional)

Make clear spec.application.dynamicPluginsConfigMapName deprecation process

Documentation Considerations

Make sure needed modifications provided in:

• Upstream doc: https://github.com/redhat-developer/rhdh-operator/blob/main/docs/configuration.md
• Downstream doc: https://docs.redhat.com/en/documentation/red_hat_developer_hub/1.4/html/configuring/provisioning-and-using-your-custom-configuration#provisioning-and-using-your-custom-configuration