Following-up on a Mail thread, we'd like to put the following issue back to awareness and potentially ask for an RFE on this.

Context

• We are working on enabling RHODS to use KServe (which uses Knative/aka. OpenShift Serverless behind the scenes). KServe uses upstream Istio. With Service Mesh we faced an issue with init-containers as SM is using istio-cni.
• The issue and its workarounds is outlined in istio-docs here: https://istio.io/latest/docs/setup/additional-setup/cni/#compatibility-with-application-init-containers. 
• The full context is documented here: https://docs.google.com/document/d/1THocVo2A5WWj-UlFTu2ODi352Q5PnbUmhxdza2suMXA/edit 

Current communication

Happened in a mail thread, here the relevant parts:

Stavros:
1337 uid is not really ideal to use as we need `anyuid` scc.

Aslak Knutsen:
In OSSM the proxy runs using the "Application".runAsUID +1, and "Application".runAsUID can be provided by OpenShift. anyuid shouldn't be needed in this case.
OCP annotates the Namespace with openshift.io/sa.scc.uid-range: 1000710000/10000 and will always run a pod with the first uid in the range if runAsUID is not provided by the user.

Stavros/Reto:
Regarding the uid issue, Reto just verified that having the sidecar container run with an id from the project id range and setting the same id to the init container works for KServe. However this means:
- If you want to use an init container with SM & CNI you need to manually findout the project uid range and guess or calculate (runtimeUid+1) for the SM sidecar id value, so you can run both containers with the same id.

It would be super useful to improve that at the SM side if possible to unblock KServe, without having to patch KServe with a special hack.

The current solution is based on knowing SM internas (which user is used as for the proxy-container) and OpenShift custom annotation that must be known and handled in KServe code. This is quite hacky and might cause issues in the future if for example SM changes that behaviour. As this is not a "public api" we would like to omit using that approach. Also we have some douts that we can bring that into the upstream KServe codebase.

Please feel free to modify/move this ticket in any way, if it is not in the right place.