Value Statement

As an MCE user configuring OpenShift cluster discovery, I want to filter discovered clusters by cluster types and infrastructure providers, so that I can discover only the clusters that are relevant to my needs and have a consistent experience with OpenShift Cluster Manager.

Description
Currently, the Discovery Config UI allows filtering discovered clusters by "last active" time and OpenShift version. This enhancement will add two additional filter capabilities:

1. Cluster Type: Filter by the platform type of the cluster (OCP, ROSA, ARO, etc.)
2. Infrastructure Provider: Filter by where the clusters are running (AWS, Azure, GCP, etc.)

These additions will help administrators manage large-scale environments more efficiently by allowing them to focus on specific cluster types or infrastructure providers.

Acceptance Criteria

1. Add a "Cluster Types" multi-select dropdown to the Discovery Config UI that allows users to select from the following options:
   1. OSD (OpenShift Dedicated)
   2. OSDTrial (Trial version of OpenShift Dedicated)  
   3. OCP (OpenShift Container Platform)
   4. RHMI (Red Hat Managed Integration)
   5. ROSA (Red Hat OpenShift on AWS)
   6. RHOIC (Red Hat OpenShift on IBM Cloud)
   7. MOA
   8. MOA-HostedControlPlane
   9. ROSA-HyperShift (ROSA with HyperShift)
   10. ARO (Azure Red Hat OpenShift)
   11. OCP-AssistedInstall (OpenShift Assisted Installer)
        

2. Add an "Infrastructure Providers" multi-select dropdown to the Discovery Config UI that allows users to select from the following options:
   - aws
   - azure
   - baremetal
   - external
   - gcp
   - ibmcloud
   - kubevirt
   - libvirt
   - none
   - nutanix
   - openstack
   - ovirt
   - powervs
   - vsphere

3. Display user-friendly names for these options in the UI while sending the correct backend values to the API.

4. Add appropriate labels and help text for both new filter options.

5. Allow users to select multiple values for both filter types.

6. Ensure the filters are included in the DiscoveryConfig resource that is sent to the backend.

7. Update the Discovery Config UI to reflect the current filter selections when editing an existing configuration.

8. Add appropriate translations for all new UI elements.

9. Ensure the UI layout remains consistent with the existing filter controls.

Definition of Done for Engineering Story Owner (Checklist)

1. Both filter dropdowns are implemented and working correctly
2.  Selected filters are properly saved in the DiscoveryConfig resource
3. Filter selections are correctly loaded when editing existing configurations
4. Help text and labels are clear and helpful
5. All new UI elements are translated
6. The UI is responsive and maintains consistent layout
7. Manual testing confirms that the filters work correctly in the UI

Development Complete

• The code is complete.
• Functionality is working.
• Any required downstream Docker file changes are made.

Tests Automated

• [ ] Unit/function tests have been automated and incorporated into the
  build.
• [ ] 100% automated unit/function test coverage for new or changed APIs.

Secure Design

• [ ] Security has been assessed and incorporated into your threat model.

Multidisciplinary Teams Readiness

• [ ] Create an informative documentation issue using the Customer

Portal Doc template that you can access from [The Playbook](

https://docs.google.com/document/d/1YTqpZRH54Bnn4WJ2nZmjaCoiRtqmrc2w6DdQxe_yLZ8/edit#heading=h.9fvyr2rdriby),

and ensure doc acceptance criteria is met.

• Call out this sentence as it's own action:

• [ ] Link the development issue to the doc issue.

Support Readiness

• [ ] The must-gather script has been updated.