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

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

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Critical Critical
    • 1.7.0
    • None
    • Marketplace, UI
    • 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
    • Release Note Not Required

      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.

              dsantra12 Debsmita Santra
              cjerolim Christoph Jerolimov
              RHIDP - Frontend Plugins & UI
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: