Discussion: do we want to keep net-certmanager or can we integrate in Serving

[ReToCode]

Relates to the discussion in #14720.

Overall, it begs the question if we even need net-certmanager as a separate component and the KnativeCertificate abstraction. When http01 is deprecated and removed, there is only one implementation left.

Arguments

• Mainly maintainability: we are only three active people maintaining a lot of repos --> just bumping, updating generators and stuff is a lot of work
• Easier to install and configure:
  • People do not need to install and additional component in YAML
  • The installation in operator is not solved: No option to install net-certmanager-controller operator#950
• Eventing uses cert-manager directly
• We can have a separate controller in Serving-controller, only starting when encryption is enabled and cert-manager CRDs are present

@skonto please add more points and link to upcoming Serving WG meeting.

[skonto]

I would add:

• net-certmanager does not do much, basically it translates Knative certificates to cert-manager certificates. Given that Eventing integrates with cert-manager directly, I think that the right abstraction to integrate is that of a configmap/secret. Most projects out there do the latter. Not sure why Serving needs to do more as long as steps are documented we should be fine.
• Serving already has several deployments and we should consider simplifying the deployment model.

[dprotaso]

I think integrating makes sense - let's formalize a plan - cause we'll need a migration path for existing users

[dprotaso]

Given a migration we might want consider re-working some things - eg. knative-extensions/net-certmanager#353

[dprotaso]

also related: knative/operator#1621 (comment)

[skonto]

/assign @skonto