Uploaded image for project: 'WildFly WIP'
  1. WildFly WIP
  2. WFWIP-502

Migration path between EAP7 and EAP8 images when provisioning.xml depends on builder image maven repo

    XMLWordPrintable

Details

    Description

      We have this special scenario where we are testing application with <app>/galleon/provisioning.xml:

      <installation xmlns="urn:jboss:galleon:provisioning:3.0">
          <feature-pack location="eap-s2i@maven(org.jboss.universe:s2i-universe):current">
              <default-configs inherit="false"/>
              <packages inherit="false"/>
          </feature-pack>
          <config model="standalone" name="standalone.xml">
              <layers>
                  <include name="jaxrs"/>
                  <include name="cdi"/>
                  <include name="jpa"/>
              </layers>
          </config>
          <options>
              <option name="optional-packages" value="passive+"/>
          </options>
      </installation>
      

      With EAP7 images, this app works ok, because galleon provisioning step has access maven repo integrated to S2I builder image which contains necessary artifacts (and thus we didn't have to care about any versions here).

      Now with EAP8 builder image, there is no maven repo integrated, so the proposed step from analysis to use legacy S2I mode (GALLEON_USE_LOCAL_FILE=true) isn't working.

      I know that file can contain concrete feature-pack GAV. But it was so tempting to use it without version for easy upgrades of images that I suppose there definitely will be someone using it like this. And for that someone the workflow would be broken now.
      We even have it listed as an example in documentation https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html-single/getting_started_with_jboss_eap_for_openshift_container_platform/index#custom-provisioning-files-jboss-eap_default

      EAP7-1734 and EAP7-1735 cover the use of feature pack (and channel) so those are obvious artifacts that need to be available in used maven repository. But the example above requires additional artifacts, not covered in either RFE, which where previously included in the image.

      Attachments

        Issue Links

          Activity

            People

              jmesnil1@redhat.com Jeff Mesnil
              jbliznak@redhat.com Jan Blizňák
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: