Open shift BPM image use of multiple kjars in container scenario
Issue
The openshift image currently supports multiple kjar versions through deployment to the same container using the flag KIE_CONTAINER_DEPLOYMENT or KIE_CONTAINER_DEPLOYMENT_OVERRIDE.
This paradigm does not fit for immutable containers and has a serious flaw with continuous pipelines which every Openshift customer will be using.
The scenario example is:
KIE_CONTAINER_DEPLOYMENT=null
Build 1 - Nothing is currently in production, build goes through the pipeline and waits for approval. On approval the build is deployed to production and our KIE_CONTAINER_DEPLOYMENT is updated.
KIE_CONTAINER_DEPLOYMENT=“build1"
Build 2 - Takes KIE_CONTAINER_DEPLOYMENT and appends its own build onto the variable - “build1 + build2". This is then built and goes through the pipeline and waits for approval.
Build 3 - Takes KIE_CONTAINER_DEPLOYMENT of “build1” and appends its own build onto the variable “build1 + build3”. This is then build and goes through the pipeline and waits for approval.
Build 2 is then promoted to production.
What happens to build 3? Build 3 and all subsequent requests are now invalid.
The underlying issue is we are expected to package multiple kjars inside the same container and its this which does not fit into the paradigm. The solution for this is to re-implement the alias redirection as a proxy which routes to different openshift services / pods based on the request.
Environment
- Openshift Container Platform
- 3.3.1
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
