-
Enhancement
-
Resolution: Done
-
Major
-
None
The quarterly release cadence of EAP CD doesn't play nicely with shared, single branch structure of jboss-container-images/jboss-eap-modules. Each quarterly release may have new things (e.g. CD 14 has several new extensions; CD 15 should have at least one) that we want in standalone-openshift.xml, but if an image not associated with that current CD tries to use that config, it will fail.
In the various scripts etc in jboss-eap-modules we should ensure the module works across releases, thus allowing images to use HEAD. Perhaps an image (say CD 13) would normally be fixed to a tag (say Sprint 21) of the modules, but if there was a need to move forward (say to fix a bug) it should be possible to move to HEAD, or a later sprint tag, without fear of bringing in an incompatible standalone-openshift.xml.
The best way I see to solve this is to use a separate module per release. I think this is basically how it's been done in the past in cct_module; it's just that now there are more frequent releases.
Once we stop producing images for a release we can remove its module, so this need not result in a huge proliferation of modules. I expect 2 to 3 depending on where we are in dev cycles. One for the current LTS image stream (EAP on OS 7.2), one for current released CD (for bug fixes), one for the current in dev CD, once work on that one reaches the point where we want to update standalone-openshift.xml.
- blocks
-
CLOUD-2728 Expose EAP "Tracing" information so that it can be consumed by OpenShift Console
- Verified
-
CLOUD-2729 Support Eclipse MicroProfile Config
- Verified
-
CLOUD-2730 Implement EAP Health Check so that it can be consumed by OpenShift Console
- Verified
- incorporates
-
CLOUD-2942 EAP CD 14 Release
- Closed
- is related to
-
CLOUD-2921 Remove standalone-openshift.xml from jboss-eap-cd-openshift-launch module
- Closed