Red Hat Summit2.1 Release Notes
Release Notes for OpenShift Enterprise
Abstract
Chapter 1. Introduction to OpenShift Enterprise
1.1. Installing OpenShift Enterprise 2.1
1.2. Upgrading to OpenShift Enterprise 2.1
Chapter 2. New Features
2.1. What's New in OpenShift Enterprise 2.1
OpenShift Enterprise now supports the following cartridges through the use of the Software Collections Library (SCL):
- PHP 5.4
- MySQL 5.5
Administrators can now configure platform components and developer applications to log messages using Syslog. This enables administrators to optionally configure a Syslog implementation to send logs directly to a remote logging server or monitoring solution without having to first write the messages locally to disk. See the OpenShift Enterprise Administration Guide and OpenShift Enterprise User Guide at https://access.redhat.com/site/documentation for more information on log management.
Metrics including cgroups, cartridge, and application information can now be gathered and published at a configurable interval for all gears on a node host using a Watchman plug-in. Cartridge and application authors may also publish metrics at a schedule of their own choosing, instead of waiting for the plug-in to invoke the metrics action hook. See the OpenShift Enterprise Administration Guide at https://access.redhat.com/site/documentation for more information on metrics collection.
Administrators can now group nodes into regions and zones, which can represent physical geographies, such as different countries or data centers, or can be used to provide network level separation between node environments. This feature allows brokers to manage several distinct geographies by controlling application deployments across a selected group of nodes. The broker attempts to distribute new gears evenly across the available zones; if the default gear placement algorithm is not desired, a custom gear placement plug-in can be implemented. See the OpenShift Enterprise Administration Guide at https://access.redhat.com/site/documentation for more information on regions, zones, and customizing the gear placement algorithm.
Developers and administrators can now create and manage teams, which can be added to domains as collaborators. Multiple developers can be added to a team, which counts as a single member with either view, edit, or admin permissions when added to a domain. Teams are controlled by developers, whereas global teams are controlled by system administrators. Global teams can also be synced with LDAP groups, and optionally create OpenShift Enterprise accounts for any LDAP users that do not already exist. See the OpenShift Enterprise Administration Guide and OpenShift Enterprise User Guide at https://access.redhat.com/site/documentation for more information on teams, including global teams.
Administrators can now configure Watchman, an optional tool that monitors the state of gears and cartridges. It is primarily used to automatically take action to restore any gears that have ceased to function to their most recent configuration. Plug-ins can be used to expand the events and conditions on which the Watchman tool takes action, such as throttling CPU usage and reacting to out-of-memory exceptions from JBoss cartridges. See the OpenShift Enterprise Administration Guide at https://access.redhat.com/site/documentation for more information on configuring Watchman.
2.2. Notable Technical Changes
Distinct channels have been created for OpenShift Enterprise 2.1 for both RHN Classic and Red Hat Subscription Management. See the OpenShift Enterprise Deployment Guide for an updated list of channel names and for more information on available repositories.
Cartridges are now managed by the broker. Before cartridges can be used in applications, administrators must use the new oo-admin-ctl-cartridge command on the broker host to import cartridge manifests from nodes and migrate cartridges to the latest active version. While this step is performed automatically during upgrades to OpenShift Enterprise 2.1 using the ose-upgrade tool or initial installations using the installation utility, it must be performed by administrators after initial installations using the installation scripts or the step-by-step installation instructions. It must also be performed after any future cartridge installations or updates. See the latest OpenShift Enterprise Deployment Guide for instructions after an initial installation, and the OpenShift Enterprise Administration Guide for more detailed usage.
Districts are now required before applications can be deployed. While district creation is performed automatically during initial installations of OpenShift Enterprise 2.1 using the installation utility, it must be performed by administrators after initial installations using the installation scripts or the step-by-step installation instructions. It also must be performed after upgrading to OpenShift Enterprise 2.1 using the ose-upgrade tool if districts did not already exist prior to the upgrade. See the latest OpenShift Enterprise Deployment Guide for basic information on gear profiles and creating districts after an initial installation, and the OpenShift Enterprise Administration Guide for more detailed information on capacity planning and districts.
MCollective is now upgraded to version 2.4 to address a number of bugs. This upgrade includes a number of configuration changes, such as deprecating the topicprefix setting, disabling direct addressing, and removing the registerinterval setting. See https://bugzilla.redhat.com/show_bug.cgi?id=1079365 for more information.
To avoid permission errors related to Apache, the MCollective client is now configured to log to the console at log level warn instead of writing to a file at log level debug. See https://bugzilla.redhat.com/show_bug.cgi?id=963332 for more information.
Chapter 3. Known Issues
When using RHN Classic, the oo-admin-yum-validator --oo-version 2.1 --fix-all command does not automatically subscribe a system to the OpenShift Enterprise 2.1 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.1, 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.
IPv6 is not supported for the 2.1 release, and OpenShift Enterprise has not been tested using IPv6. Some components that may be affected are listed in the bug report.
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.
Chapter 4. Asynchronous Errata Updates
Note
The latest OpenShift Enterprise Deployment Guide provides general instructions on how to apply asynchronous errata updates within a minor release. Some errata have additional instructions specific to that release that must be performed to fully apply the update to a host. The general instructions provided in the OpenShift Enterprise Deployment Guide reference Table 4.1, “Additional Update Instructions per Release” in this section, which details the releases that require additional steps.
yum update command on a host installs packages for all pending updates at once. If you are applying multiple asynchronous errata updates at once, any additional update instructions for all releases being installed must be performed. However, the steps can be aggregated in this situation when commands would be unnecessarily repeated. When evaluating which additional steps must be performed for multiple pending asynchronous errata updates, consider the following general workflow:
- Run the
yum updatecommand on each host. - Restart relevant services.
- Import, activate, and migrate the latest cartridge manifests on the broker host, if relevant.
- Run the
oo-admin-upgradecommand on the broker host to upgrade existing gears, if relevant.
Example 4.1. Applying Multiple Asynchronous Errata Updates at Once
- After running the
yum updatecommand on each host, run the following on each node host:#
service ruby193-mcollective restart#service openshift-watchman restart - Run the following on the broker host:
#
service openshift-broker restart#service openshift-console restart#oo-admin-ctl-cartridge -c import-node --activate --obsolete#oo-admin-ctl-cartridge -c migrate#oo-admin-upgrade archive#oo-admin-upgrade upgrade-node --version=2.1.5Note that theoo-admin-upgrade upgrade-nodecommand is only run once, using the version for the latest release being applied.
| Release | Advisory | Additional Instructions |
|---|---|---|
| 2.1.1 | RHBA-2014:0600 |
After running the
yum update command on each host and ensuring all packages have been updated, restart the ruby193-mcollective service on each node host:
#
On the broker host, restart the broker service and, if installed, the console service:
#
On the broker host, import and activate the latest cartridge manifests, then migrate old cartridge versions to the latest active versions. Note that this may also activate cartridges that you have previously deactivated, so you may need to again deactivate any cartridges that you want to remain deactivated.
#
On the broker host, archive previous upgrade data and upgrade all nodes. Alternatively, to only upgrade a single node or gear, see the OpenShift Enterprise Deployment Guide for other
oo-admin-upgrade command usage and use 2.1.1 as the target --version.
# |
| 2.1.2 | RHBA-2014:0781 |
After running the
yum update command on each host and ensuring all packages have been updated, further steps are required to apply the bug fix for BZ#1102325 to existing gears. If you have changed the front-end server proxy plug-in on any node host from the default to the apache-vhost plug-in, you must rebuild the HTTP front-end configuration for those hosts. Note that this causes a node outage, and Red Hat recommends rebuilding during a planned broker maintenance outage.
Run the following commands on affected node hosts to rebuild the HTTP front-end configuration:
#
See the OpenShift Enterprise Administration Guide for instructions on enabling maintenance mode and the OpenShift Enterprise Deployment Guide for full documentation on front-end proxy server plug-ins including modifying their configuration.
|
| 2.1.3 | RHBA-2014:0878 |
After running the
yum update command on each host and ensuring all packages have been updated, restart the ruby193-mcollective service on each node host:
#
If Rsyslog 7 is installed, restart the
rsyslog7 service on each node host:
#
On the broker host, import and activate the latest cartridge manifests, then migrate old cartridge versions to the latest active versions. Note that this may also activate cartridges that you have previously deactivated, so you may need to again deactivate any cartridges that you want to remain deactivated.
#
On the broker host, archive previous upgrade data and upgrade all nodes. Alternatively, to only upgrade a single node or gear, see the OpenShift Enterprise Deployment Guide for other
oo-admin-upgrade command usage and use 2.1.3 as the target --version.
# |
| 2.1.4 | RHBA-2014:0999 |
After running the
yum update command on each host and ensuring all packages have been updated, restart the ruby193-mcollective and openshift-watchman services on each node host:
#
On the broker host, restart the broker service and, if installed, the console service:
#
On the broker host, import and activate the latest cartridge manifests, then migrate old cartridge versions to the latest active versions. Note that this may also activate cartridges that you have previously deactivated, so you may need to again deactivate any cartridges that you want to remain deactivated.
#
On the broker host, archive previous upgrade data and upgrade all nodes. Alternatively, to only upgrade a single node or gear, see the OpenShift Enterprise Deployment Guide for other
oo-admin-upgrade command usage and use 2.1.4 as the target --version.
# |
| 2.1.5 | RHBA-2014:1095 |
After running the
yum update command on each host and ensuring all packages have been updated, restart the ruby193-mcollective and openshift-watchman services on each node host:
#
On the broker host, restart the broker service and, if installed, the console service:
#
On the broker host, import and activate the latest cartridge manifests, then migrate old cartridge versions to the latest active versions. Note that this may also activate cartridges that you have previously deactivated, so you may need to again deactivate any cartridges that you want to remain deactivated.
#
On the broker host, archive previous upgrade data and upgrade all nodes. Alternatively, to only upgrade a single node or gear, see the OpenShift Enterprise Deployment Guide for other
oo-admin-upgrade command usage and use 2.1.5 as the target --version.
# |
| 2.1.6 | RHBA-2014:1183 |
After running the
yum update command on each host and ensuring all packages have been updated, add the following settings to the /opt/rh/ruby193/root/etc/mcollective/client.cfg file on the broker host:
# Broker will retry ActiveMQ connection, then report error plugin.activemq.initial_reconnect_delay = 0.1 plugin.activemq.max_reconnect_attempts = 6
Add the following settings to the
/opt/rh/ruby193/root/etc/mcollective/server.cfg file on each node host:
# Node should retry connecting to ActiveMQ forever plugin.activemq.max_reconnect_attempts = 0 plugin.activemq.initial_reconnect_delay = 0.1 plugin.activemq.max_reconnect_delay = 4.0
On each node host, restart the
ruby193-mcollective and openshift-watchman services:
#
On the broker host, restart the broker service:
#
On the broker host, import and activate the latest cartridge manifests, then migrate old cartridge versions to the latest active versions. Note that this may also activate cartridges that you have previously deactivated, so you may need to again deactivate any cartridges that you want to remain deactivated.
#
On the broker host, archive previous upgrade data and upgrade all nodes. Alternatively, to only upgrade a single node or gear, see the OpenShift Enterprise Deployment Guide for other
oo-admin-upgrade command usage and use 2.1.6 as the target --version.
#
To apply the bug fix for BZ#1135062 to existing gears that include MongoDB cartridges, see https://access.redhat.com/articles/1179613.
|
| 2.1.7 | RHBA-2014:1353 |
After running the
yum update command on each host and ensuring all packages have been updated, restart the ruby193-mcollective service on each node host:
#
On the broker host, restart the broker service:
#
On the broker host, import and activate the latest cartridge manifests, then migrate old cartridge versions to the latest active versions. Note that this may also activate cartridges that you have previously deactivated, so you may need to again deactivate any cartridges that you want to remain deactivated.
#
On the broker host, archive previous upgrade data and upgrade all nodes. Alternatively, to only upgrade a single node or gear, see the OpenShift Enterprise Deployment Guide for other
oo-admin-upgrade command usage and use 2.1.7 as the target --version.
# |
| RHBA-2014:1630 |
After running the
yum update command on each host and ensuring all packages have been updated, restart the ruby193-mcollective service on each node host:
#
On the broker host, import and activate the latest cartridge manifests, then migrate old cartridge versions to the latest active versions. Note that this may also activate cartridges that you have previously deactivated, so you may need to again deactivate any cartridges that you want to remain deactivated.
#
On the broker host, archive previous upgrade data and upgrade all nodes. Alternatively, to only upgrade a single node or gear, see the OpenShift Enterprise Deployment Guide for other
oo-admin-upgrade command usage and use 2.1.7 as the target --version.
# | |
| RHBA-2014:1656 |
After running the
yum update command on each host and ensuring all packages have been updated, restart the ruby193-mcollective service on each node host:
#
On the broker host, import and activate the latest cartridge manifests, then migrate old cartridge versions to the latest active versions. Note that this may also activate cartridges that you have previously deactivated, so you may need to again deactivate any cartridges that you want to remain deactivated.
#
On the broker host, archive previous upgrade data and upgrade all nodes. Alternatively, to only upgrade a single node or gear, see the OpenShift Enterprise Deployment Guide for other
oo-admin-upgrade command usage and use 2.1.7 as the target --version.
# | |
| RHEA-2014:1716 |
See the OpenShift Enterprise Deployment Guide for information on the new JBoss Fuse, JBoss A-MQ, and JBoss Fuse Builder cartridges.
| |
| 2.1.8 | RHEA-2014:1807 |
After running the
yum update command on each host and ensuring all packages have been updated, see the OpenShift Enterprise Deployment Guide for instructions on upgrading from OpenShift Enterprise release 2.1 to release 2.2.
|
| 2.1.9 | RHSA-2014:1906 |
After running the
yum update command on each host and ensuring all packages have been updated, restart the ruby193-mcollective service on each node host:
#
On the broker host, import and activate the latest cartridge manifests, then migrate old cartridge versions to the latest active versions. Note that this may also activate cartridges that you have previously deactivated, so you may need to again deactivate any cartridges that you want to remain deactivated.
#
On the broker host, archive previous upgrade data and upgrade all nodes. Alternatively, to only upgrade a single node or gear, see the OpenShift Enterprise Deployment Guide for other
oo-admin-upgrade command usage and use 2.1.9 as the target --version.
# |
| 2.1.10 | RHBA-2015:0078 |
After running the
yum update command on each host and ensuring all packages have been updated, there are no additional update instructions for this release.
|
| 2.1.11 | RHBA-2015:1589 |
After running the
yum update command on each host and ensuring all packages have been updated, there are no additional update instructions for this release.
|
| 2.1.12 | RHEA-2015:1590 |
After running the
yum update command on each host and ensuring all packages have been updated, there are no additional update instructions for this release.
|
Chapter 5. Product Support and Documentation
Product support is available at http://www.redhat.com/support.
Product documentation for OpenShift Enterprise is available at https://access.redhat.com/knowledge/docs/OpenShift_Enterprise/.
Appendix A. Revision History
| Revision History | |||||
|---|---|---|---|---|---|
| Revision 2.0-16 | Tue Aug 11 2015 | ||||
| |||||
| Revision 2.0-15 | Tue Nov 25 2014 | ||||
| |||||
| Revision 2.0-14 | Thu Nov 6 2014 | ||||
| |||||
| Revision 2.0-13 | Thu Oct 23 2014 | ||||
| |||||
| Revision 2.0-12 | Thu Oct 16 2014 | ||||
| |||||
| Revision 2.0-11 | Wed Oct 15 2014 | ||||
| |||||
| Revision 2.0-10 | Thu Oct 2 2014 | ||||
| |||||
| Revision 2.0-9 | Tue Sep 16 2014 | ||||
| |||||
| Revision 2.0-8 | Thu Sep 11 2014 | ||||
| |||||
| Revision 2.0-7 | Tue Aug 26 2014 | ||||
| |||||
| Revision 2.0-6 | Mon Aug 4 2014 | ||||
| |||||
| Revision 2.0-4 | Mon Jul 14 2014 | ||||
| |||||
| Revision 2.0-3 | Mon Jun 23 2014 | ||||
| |||||
| Revision 2.0-2 | Wed Jun 4 2014 | ||||
| |||||
| Revision 2.0-1 | Fri May 16 2014 | ||||
| |||||
