operand-deployment-lifecycle-manager

operand-deployment-lifecycle-manager copied to clipboard

It would be useful to have a global install log to be able to monitor the progress of the odlm install that marks the start and finish of each of components during the install. That would allow us to more easily identify which areas are taking the longest to install and what else was also being installed at the same time. And having that knowledge is important when we start to look at how to optimize and reduce the install time.

A global install log would also be useful for debugging to see which which components are still progressing or are potentially hanging during the install process.

@horis233 @IBM/odlm-maintainers ^^

Yes, we can enable the global install log in the debug mode.

Also, I am considering optimizing and reducing the install time as well.

Currently, we deploy operator can CR one by one. We can save time by installing them batch by batch. For example, creating 5 subscriptions simultaneously.

Also, for the uninstall, ODLM will wait until one CR is deleted then delete the next one. It may cause that one CR uninstall blocks others. We can delete all the CRs from one operator in parallel.

Yes, we can enable the global install log in the debug mode.

Debug mode is good, but I think we can also leverage the kubectl-odlm as well to show the status of install.

@horis233 another comment is I was hoping we can have some script which can help me to filter out the installation monitor log, so it would be great to have some key words for logging pattern for this.

@gyliu513 What would keep us from having ODLM report this in the status of the CRs, effectively the API communication we are currently using?

Any information that may not be useful as a condition could be registered in k8s as an event.

This way we don't have to build out additional tooling and constructs, and our clients can use familiar APIs and API extension.

@taylormgeorge91 event is good, but here the problem is which resource event can help. We want a central point to get all status of operators managed by ODLM, but ODLM do not have such a resource yet, any comments?

@horis233 ^^

Hi @gyliu513 Maybe we can look at what OpenShift has done with ClusterOperator

https://github.com/openshift/cluster-version-operator/blob/master/docs/dev/clusteroperator.md

I would like to utilize these conditions for install/upgrade: https://pkg.go.dev/github.com/openshift/api/config/v1#ClusterStatusConditionType

We would need to obtain this information through ODLM otherwise we would have to post-process the CRs managed by ODLM to obtain this information.

Also here: https://pkg.go.dev/github.com/openshift/api/config/v1#ClusterVersionStatus