Previously we kept the s3 profiles as separate item in the reports, since ramen config does not provide a way to match s3 profiles to clusters.
However the drcluster contains:
spec:
s3ProfileName: minio-on-dr1
In validate clusters we can use the drclusters to match profiles with the clusters, and display the s3 profiles in the cluster pane. This makes it easier to debug the common case since each cluster has one s3 profile.
In validate application we don't have drclusters since kubectl-gather does not support gathering resources referenced by the drpolicy. If we teach kubectl-gather to gather the drclusters listed in the drpolicy wen can do the same change for validate application report.
The data we gather from s3 must be separate from the clusters since it is not gathered by kubectl-gather. This can be part of the cluster if we teach kubectl-gather to gather s3 data.
I'm not sure how this will work for other configurations which should be supported:
- Single s3 profile on the hub cluster: show in the hub cluster?
- External s3 store (e.g. AWS): shows as separate pane?
It seems that the only solution that works for all cases is what we have now.
Previously we kept the s3 profiles as separate item in the reports, since ramen config does not provide a way to match s3 profiles to clusters.
However the drcluster contains:
In validate clusters we can use the drclusters to match profiles with the clusters, and display the s3 profiles in the cluster pane. This makes it easier to debug the common case since each cluster has one s3 profile.
In validate application we don't have drclusters since kubectl-gather does not support gathering resources referenced by the drpolicy. If we teach kubectl-gather to gather the drclusters listed in the drpolicy wen can do the same change for validate application report.
The data we gather from s3 must be separate from the clusters since it is not gathered by kubectl-gather. This can be part of the cluster if we teach kubectl-gather to gather s3 data.
I'm not sure how this will work for other configurations which should be supported:
It seems that the only solution that works for all cases is what we have now.