add tls to kserve-router and add certs to ig service and always mount…

[VedantMahabaleshwarkar]

… serving cert secret to raw deployment

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes : RHOAIENG-18978

• create server in router with TLS using certs mounted by adding annotation service.beta.openshift.io/serving-cert-secret-name=graph_name to the graph service
• always mount service cert secret to deployments so that router can reliably find tls.crt and tls.key files

Type of changes
Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Feature/Issue validation/testing:

• create raw ig and isvcs
• all isvcs + ig deployment should have the serving secret volume mounted
• In the graph deployment, verify the graph deployment starts correctly and test the graph

Special notes for your reviewer:

1. Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Checklist:

• Have you added unit/e2e tests that prove your fix is effective or that this feature works?
• Has code been commented, particularly in hard-to-understand areas?
• Have you made corresponding changes to the documentation?

Release note:

Re-running failed tests

• /rerun-all - rerun all failed workflows.
• /rerun-workflow <workflow name> - rerun a specific failed workflow. Only one workflow name can be specified. Multiple /rerun-workflow commands are allowed per comment.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[Jooho]

General question: Is the TLS for communicating Isvc pod to Isvc pod, or is the client to router endpoint for internal access?

[VedantMahabaleshwarkar]

General question: Is the TLS for communicating Isvc pod to Isvc pod, or is the client to router endpoint for internal access?

It is for pod to pod

[Jooho]

nit: you missed some places to replace string.
I think it would be better to apply it equally everywhere.

[Jooho]

I am not sure how this pr was verified but I have some questions about tls connections between router pod and isvc pod.

If router pod is client in this scenario, I wonder how it can create SSL connection between them. Could you please elaborate this part?

[openshift-ci]

@VedantMahabaleshwarkar: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-raw	1618bc8	link	true	/test e2e-raw
ci/prow/e2e-graph	1618bc8	link	true	/test e2e-graph

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[israel-hdez]

May you rebase the PR?

[VedantMahabaleshwarkar]

I am not sure how this pr was verified but I have some questions about tls connections between router pod and isvc pod.

@Jooho clarified this with Edgar, this JIRA is not for tls from router to isvc, it is only from client to the router. So this PR only includes the tls changes for listening in the router

[Jooho]

ok then it makes more sense. please fix th ci

[israel-hdez]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: israel-hdez, VedantMahabaleshwarkar

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [VedantMahabaleshwarkar,israel-hdez]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment