Chapter 4. Known Issues

This chapter highlights known issues in the OpenShift Enterprise 2.2 release.

If needed, administrators can choose to configure the JBoss EWS cartridge tomcat7 binary provided by the EWS 3 product to work around known security issues with the JBoss EWS-2 tomcat7 binary. To enable the use of the EWS 3 tomcat7 binary, use the following command to update tomcat7 on each node:

# yum update tomcat7 --enablerepo jws-3-for-rhel-6-server-rpms
This change will affect all JBoss EWS cartridges on the node. Running JBoss EWS cartridges will not see any changes until they are restarted. All new JBoss EWS cartridges will use the updated tomcat7 binary.
If using JBoss EWS 3 binaries with the EWS 2 cartridge, ensure that you are using the Java 1.7 binaries, or you will see issues with the cartridge. EWS 3 is only certified to run with Java 1.7.

When using RHN Classic, the oo-admin-yum-validator --oo-version 2.2 --fix-all command does not automatically subscribe a system to the OpenShift Enterprise 2.2 channels, but instead reports the manual steps required. This command is also automatically run during the ose-upgrade begin step when upgrading to OpenShift Enterprise 2.2, therefore upgrades using RHN Classic also require manual intervention. After the channels are manually subscribed, running either command again sets the proper yum priorities and continues as expected.

When scaling up a scalable application with a large minimum number of gears, newly created gears are deleted automatically before the scale up is finished, until the number of gears is the same as before the scale up.

While Red Hat supports OpenShift Enterprise deployments using a mixed IPv4 and IPv6 topology starting in the 2.2 release, full IPv6 connectivity is not supported, and OpenShift Enterprise has not been tested as such. Some components that may be affected are listed in the bug report. See the OpenShift Enterprise Deployment Guide for requirements and known issues regarding IPv6 tolerance.

If you delete the Jenkins builder gear (from JBoss Developer Studio) and try to rebuild an application, the build fails because the build can not be found. This seems to be caused because Jenkins keeps a list of builders, and upon builder deletion (using REST calls), Jenkins does not get cleaned up.

Jenkins Server fails to build a re-created application that uses the same name as a previously deleted application. To workaround this issue, delete the Jenkins job before creating an application using the same name as a deleted application.