Uploaded image for project: 'Red Hat Internal Developer Platform'
  1. Red Hat Internal Developer Platform
  2. RHIDP-6758

Extensions plugin: Backend changes to load and persist dynamic plugin configurations

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Critical Critical
    • 1.7.0
    • None
    • Marketplace
    • None
    • Marketplace: Backend and UI changes to load and persist dynamic plugin configurations
    • M
    • False
    • Hide

      None

      Show
      None
    • False
    • RHIDP-6240Extensions plugin: Install and configure plugins - 1.7 - Phase 1: configure, enable, disable plugins from details page
    • Done
    • RHIDP-6240 - Extensions plugin: Install and configure plugins - 1.7 - Phase 1: configure, enable, disable plugins from details page
    • QE Needed, Docs Needed, TE Needed, Customer Facing, PX Needed
    • 0% To Do, 0% In Progress, 100% Done
    • Hide
      = Introducing plugin management by using Extensions

      In this release, {product-short} administrators can configure dynamic plugins directly within the Extensions UI. Administrators can now enable, disable, install, or edit the configuration of dynamic plugins on the Extensions Details Page.

      This is an opt-in feature that must be enabled by configuration, and it is intended for testing and development environments only; it is not recommended for production use.

      This release requires a single replica deployment and uses a persistent volume claim (PVC) for the dynamic plugin configuration file. The {product-short} backend does not automatically restart when you save configuration changes. You must restart the {product-short} application for any dynamic plugin configuration updates to take effect.
      Show
      = Introducing plugin management by using Extensions In this release, {product-short} administrators can configure dynamic plugins directly within the Extensions UI. Administrators can now enable, disable, install, or edit the configuration of dynamic plugins on the Extensions Details Page. This is an opt-in feature that must be enabled by configuration, and it is intended for testing and development environments only; it is not recommended for production use. This release requires a single replica deployment and uses a persistent volume claim (PVC) for the dynamic plugin configuration file. The {product-short} backend does not automatically restart when you save configuration changes. You must restart the {product-short} application for any dynamic plugin configuration updates to take effect.
    • Feature
    • Done

      EPIC Goal

      This Epic is "Phase 1" for an installation and configuration feature of the Marketplace.

      It expects that there is a UI to change plugin configurations.

      It should anyway include the frontend changes to load and persist the data.

      Background/Feature Origin

      As the marketplace plugin is available, we want to continue to add new features to make it even easier for customers to add/test plugins and other integrations to RHDH.

      Why is this important?

      This will allow customers to get to production faster and quicker POCs.

      User Scenarios

      1. An admin want install a plugin to test it out on a test environment. This phase is not recommended to apply changes on a production environment.

      Dependencies (internal and external)

      1. RHIDP-6170

      Acceptance Criteria

      1. The Marketplace Backend provides an API to load and update the current dynamic plugin configuration (could be overall or per plugin or per package!).
        • This configuration should not include all merged app-configs.
        • It's okay if its "one" app-config.yaml that is then loaded on the next start automatically (via the right RHDH helm chart or CR)
      2. This feature should be an opt-in feature and requires a configuration in the backend and frontend to enable it. The marketplace-backend should have also a configuration option for the app-config path.
      3. The frontend should be updated to load and update the configuration via the backend. (Again: This should be an opt-in.)
      4. The frontend should show a hint that the user must rollout the changes to see the changes.
      5. There should be documented demo configuration how to enable this feature
        • on a test environment (on a cluster).
        • and on rhdh-local.

      Note on persist storage for the configuration / PVC:

      The configuration should be saved in a persistent storage. It's not required that the backend ensure that the file is still there when a new Pod is created. It should be part of the documentation that this POC works only when

      1. the app-config YAML that is stored here is stored into any persistent storage / PVC
      2. the Deployment replica count must be 1 (is that true if the same PVC is mounted into multiple Pods?)

      Note from jfargett@redhat.com: It's also fine to save these data into the database. But in the architecture call we discussed that we want save it into a file for now.

      Non goals

      1. It's not required that the Backend automatically restarts the application.

              rh-ee-dzemanov Dominika Zemanovicova
              cjerolim Christoph Jerolimov
              RHIDP - Plugins
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: