Thundercloud12 commented on issue #5857: URL: https://github.com/apache/camel-k/issues/5857#issuecomment-5679698418
Hi @squakez! I've gone through the discussion and would like to pick this up if it's still open — thanks to @pkalsi97 for the groundwork here, it made this much easier to frame. My understanding of the approach, building on what you proposed: 1. Detection — check for cert-manager's CRDs (e.g. via ServerResourcesForGroupVersion on cert-manager.io/v1, similar to the existing Knative detection pattern). Absence just means "skip silently," not an error. 2. Issuer resolution — look for a ClusterIssuer by default; if none exists, fall back to a namespaced Issuer. Alternatively, the user can explicitly force an issuer name/kind via new trait fields (e.g. tlsIssuerName, tlsIssuerKind), in which case Camel K just verifies cert-manager and that issuer exist, no auto-discovery needed. 3. Annotation, not CR creation — rather than creating Certificate CRs ourselves, add the standard [cert-manager ingress-shim annotation](https://cert-manager.io/docs/usage/ingress/) to the Ingress so cert-manager handles issuance/renewal itself. 4. Opt-in — gate the auto-detect behavior behind a flag defaulting to false, so this is non-disruptive for existing users. Trigger conditions for the automatic path would be something like: TLSHosts set + TLSSecretName empty + issuer available (auto-detected or forced). On testing — I know you flagged the e2e case (a real HTTPS call against an autogenerated cert) as the trickiest part. I'd plan to spin up cert-manager with a self-signed ClusterIssuer in the e2e environment and validate the resulting secret/cert rather than hitting a public CA, unless you have a preferred pattern already in mind. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
