Excerpt from program management call:

JE (near future technical outlook)

• Change design of RHAMT on OCP: share storage instead of HTTP POST to address significant issues (DDOS, several GB of data, keycloak optional, liveness probes which cause pause to be recreated though working)
• Shared storage: avoids the issues you might get with HTTP and large data, makes it significantly faster as this data doesn’t need to be shuffled around. Supportability concern isn’t a concern: NFS and gluster is widespread in customer installations (I asked an OpenShift EMEA architect) plus there is no support for RHAMT anyways. Also addresses the security problem as the web console, which is externally exposed, doesn’t have to have set the max post size to an incredibly high value anymore.
• Keycloak optional rather than hard-baked into RHAMT: streamlining with other MW products, allow the customer to include RHAMT in their central SSO (which is supported, rather than our old-ish upstream version)
• Marco: design considerations OCP short and long term (pro’s/ con’s, trade-offs etc.)

the current immediate issues I see so far are:

• Keycloak is not optional (WINDUP-2140)
• security (potential vulnerability for DDOS) due to max post size on web-console
• results are not avaible for user although analysis is finished (because the rather large amount of data is still in the process of being transferred via http post from the executor pod to the web console pod)
• liveness probe relies on other pod which causes false pod recreations (WINDUP-2147)

the above excerpt contains a possible short term solution using shared storage as the effort should be much lower than redesigning and refactoring everything. But this task is about:

Marco: design considerations OCP short and long term (pro’s/ con’s, trade-offs etc.)

cause I am just the PM and basically don't know anything