Anik

> It feels like this is something we should probably have a veneer for, opm render also has this problem with not splitting out object types for readability. @ankitathomas while...

> unless we're absolutely positive that the feature (and the added complexity) is actually being requested by the pipeline or a group of representative operator authors. @joelanford AFAIK no pipeline/group...

Also, the `opm alpha bundle --generate` still creates an `annotations.yaml` that has the channel information in it. This should be modified too to communicate what is expected in the bundle....

Also, we probably want to set `catalogSourceReady` to 1 in both the `Idle` and `Ready` state [here](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/pkg/metrics/metrics.go#L238-L239) too.

/close as this is out of date.

Thanks for the PR @benluddy 🎉 Do you think you'll have some cycles to get this PR to a reviewable stage? Or would you prefer someone from the operator-framework team...

>The downside here is that it makes the CatalogSource a bit of a leaky abstraction by floating these pod concerns to the top We do this frequently with our APIs...

@shixuguang this is expected. The pods are owned by the CatalogSource CRs, so if you try to edit the pod, the catalog-operator reverts it back. So essentially you have the...

@bszeti olm not propagating the secrets to the namespaces that the operator is deployed in/watching(for facilitating operand images) was an explicit design decision that was made. If olm does that,...

When we do get to this, it'll be worth assessing the value add that enabling pprof profiling brings to our customer. In the context of existing OLM installations, the collect-profile...