Gather the same information from OLM managed Operators as from ClusterOperators about must-gather HOT 9 CLOSED

@jlojosnegros: The label(s) /label kind/feature cannot be applied. These labels are supported: platform/aws, platform/azure, platform/baremetal, platform/google, platform/libvirt, platform/openstack, ga, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, px-approved, docs-approved, qe-approved, downstream-change-needed, approved, backport-risk-assessed, cherry-pick-approved

from must-gather.

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from must-gather.

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

from must-gather.

@ecordell @dmesser can you all review this as a possible RFE with the OLM team to help with data collection/debugging of operators?

from must-gather.

@jlojosnegros what all do you want to collect?
oc adm inspect -A olm only gets you the ClusterServiceVersion from all namespaces; and ClusterServiceVersion objects don't define any .status.relatedObjects thus not recursion/nested collection occurs when running inspect on that resource (and this is why you only get the CSV for each operator with the oc adm inspect -A olm command).

If the CSV told us something about the 'operator' and pointed us to an object that defined .status.relatedObjects we might be able to extend the OLM collection script to pull this information but we would need to know exactly what to collect at the top level.

@kevinrizza or @awgreene what is the top level 'operator' object for operators installed by OLM?

from must-gather.

The resources collected by the OLM collection script today include any CRDs that are a part of the olm category, which includes:

• ClusterServiceVersions
• Subscriptions
• OperatorConditions
• OLMConfigs
• InstallPlans
• OperatorGroups
• CatalogSources
• Operator CRs

If the CSV told us something about the 'operator' and pointed us to an object that defined .status.relatedObjects we might be able to extend the OLM collection script to pull this information but we would need to know exactly what to collect at the top level.

The operator CR already keeps track of all resources related to the operator in it's status.Components field.

It's worth mentioning that were moving towards a new set of APIs, where a new operator api will be introduced but will effectively continue to serve the purpose of being the top-level-api.

from must-gather.

@ingvagabund I hat to keep bouncing this around; but I fundamentally think that this should be implemented at a layer 'lower' than the 'must-gather' collector.

Should we move this request to an RFE for oc adm inspect to have it travers the status.Components fields, when an operator CR is found?

xref: https://github.com/openshift/oc/blob/master/pkg/cli/admin/inspect/resource.go#L36-L120 do we just need to add a case for this in this block of code?

from must-gather.

/close

We would like more information about exactly what it is people want to see collected as it pertains to OLM information, that isn't already collected.

from must-gather.

@sferich888: Closing this issue.

from must-gather.