Bug 2187796

+++ This bug was initially created as a clone of Bug #2183196 +++

Description of problem (please be detailed as possible and provide log
snippests):
==========================================================================
With the new Fusion aaS, in Managed service, Managed Fusion Agent is being configured and currently all the resources created by it and the operator are in the namespace "managed-fusion".

We would like to request must-gather to collect all relevant logs and details from this namespace for future troubleshootings in the service




Version of all relevant components (if applicable):
=======================================================
This is independent of ODF version but is supported from ODF 4.12.2/4.12.3 and above



Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
=================================================================
Yes while reporting Managed Fusion Agent related issues

Is there any workaround available to the best of your knowledge?
=========================================================================
NO. COllecting yaml files manually as of now

Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?
====================================================================================
3

Can this issue reproducible?
=================================
Always

Can this issue reproduce from the UI?
========================================
Not Applicable

If this is a regression, please provide more details to justify this:
========================================================================
No, new feature support. Contact point could be Dhruv Bindra for more details

Steps to Reproduce:
==============================
1. Create a ODF to ODF cluster with ROSA 4.12 and on one of the cluster, install the agent following the doc [1]
2. Collect must-gather to include logs from the managed-fusion namespace 
P.S: (the name might change , hence request the assignee to please discuss with Dhruv on the best possible solution for enabling this)
3.
[1] https://docs.google.com/document/d/1Jdx8czlMjbumvilw8nZ6LtvWOMAx3H4TfwoVwiBs0nE/edit?hl=en&forcehl=1#

Actual results:
=================================
Must-gather doesn't have the changes yet to collect logs from managed-fusion namespace


Expected results:
========================
Include the ability to collect logs from managed-fusion namespace in Provider and consumer clusters for Managed services (not needed for the ODF product in general)


Additional info:

--- Additional comment from Neha Berry on 2023-03-30 14:41:59 UTC ---

Sharing few resources from the managed-fusion namespace

oc get all -n managed-fusion

NAME                                                                  READY   STATUS      RESTARTS   AGE
pod/7612a94d3274dfdcca0bf18877eecc53dbf8f48c838c566b55afc60c50plnv8   0/1     Completed   0          89m
pod/aa81bdc456d1217c73a984454ce9d2186315d4769b17f6117042604c09d6n2x   0/1     Completed   0          89m
pod/alertmanager-managed-fusion-alertmanager-0                        2/2     Running     0          84m
pod/managed-fusion-aws-data-gather-d8df85757-wczps                    1/1     Running     0          88m
pod/managed-fusion-catsrc-g9msm                                       1/1     Running     0          89m
pod/managed-fusion-controller-manager-5c7597c66d-scnpq                2/2     Running     0          88m
pod/prometheus-managed-fusion-prometheus-0                            3/3     Running     0          84m
pod/prometheus-operator-98d7c8899-2ldmc                               1/1     Running     0          88m

NAME                                                        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
service/alertmanager-operated                               ClusterIP   None            <none>        9093/TCP,9094/TCP,9094/UDP   84m
service/managed-fusion-catsrc                               ClusterIP   172.30.34.165   <none>        50051/TCP                    89m
service/managed-fusion-controller-manager-metrics-service   ClusterIP   172.30.98.102   <none>        8443/TCP                     88m
service/prometheus                                          ClusterIP   172.30.76.185   <none>        9339/TCP                     84m
service/prometheus-operated                                 ClusterIP   None            <none>        9090/TCP                     84m

NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/managed-fusion-aws-data-gather      1/1     1            1           88m
deployment.apps/managed-fusion-controller-manager   1/1     1            1           88m
deployment.apps/prometheus-operator                 1/1     1            1           88m

NAME                                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/managed-fusion-aws-data-gather-d8df85757       1         1         1       88m
replicaset.apps/managed-fusion-controller-manager-5c7597c66d   1         1         1       88m
replicaset.apps/prometheus-operator-98d7c8899                  1         1         1       88m

NAME                                                        READY   AGE
statefulset.apps/alertmanager-managed-fusion-alertmanager   1/1     84m
statefulset.apps/prometheus-managed-fusion-prometheus       1/1     84m

NAME                                                                        COMPLETIONS   DURATION   AGE
job.batch/7612a94d3274dfdcca0bf18877eecc53dbf8f48c838c566b55afc60c509802f   1/1           8s         89m
job.batch/aa81bdc456d1217c73a984454ce9d2186315d4769b17f6117042604c09df78c   1/1           8s         89m

--- Additional comment from RHEL Program Management on 2023-03-30 14:42:05 UTC ---

This bug having no release flag set previously, is now set with release flag 'odf‑4.13.0' to '?', and so is being proposed to be fixed at the ODF 4.13.0 release. Note that the 3 Acks (pm_ack, devel_ack, qa_ack), if any previously set while release flag was missing, have now been reset since the Acks are to be set against a release flag.

--- Additional comment from RHEL Program Management on 2023-04-10 18:56:04 UTC ---

This BZ is being approved for ODF 4.13.0 release, upon receipt of the 3 ACKs (PM,Devel,QA) for the release flag 'odf‑4.13.0

--- Additional comment from RHEL Program Management on 2023-04-10 18:56:04 UTC ---

Since this bug has been approved for ODF 4.13.0 release, through release flag 'odf-4.13.0+', the Target Release is being set to 'ODF 4.13.0