Uploaded image for project: 'Cloud Enablement'
  1. Cloud Enablement
  2. CLOUD-2838

Separate standalone-openshift.xml provisioning from jboss-eap-cd-openshift-launch modules; move to per-release modules



      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.

        Gliffy Diagrams


            Issue Links



                • Assignee:
                  brian.stansberry Brian Stansberry
                  brian.stansberry Brian Stansberry
                • Votes:
                  0 Vote for this issue
                  3 Start watching this issue


                  • Created: