Re-evaluate using cert-manager as a direct dependency in release installation instructions

[timflannagan]

Goal: re-evaluate whether our installation process should have a direct dependency on the cert-manager project.

The current rukpak stack has a hard dependency on the cert-manager project to manage the certificates for the various webhooks this project deploys.

See the conversation in https://github.com/operator-framework/rukpak/pull/316#discussion_r865133374 for more information.

[github-actions[bot]]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.

[fgiloux]

Seconding the request here. I see the dependency as problematic:

• cert-manager itself cannot be installed and upgrades / uninstall cannot be managed by OLM/RukPak
• an existing version on the cluster may conflict with the instructions from RukPak release page and may not be compatible with RukPak

Possible considerations:

• shipping optionally cert-manager with OLM/RukPak, possibly with a different API group. This has the drawback that it needs to be maintained by the RukPak project.
• using a built-in mechanism for cert-management. Drawback: non-trivial.
• using Kubernetes CSR mechanism?

[github-actions[bot]]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.