Red Hat Enterprise MRG 1.3

MRG Release Notes

Release Notes for the Red Hat Enterprise MRG 1.3 Release

Edition 1

Logo

Lana Brindley

Red Hat Engineering Content Services

Legal Notice

Copyright © 2010 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

Abstract

These Release Notes contain important information available at the time of release of Red Hat Enterprise MRG 1.3. Known problems, resources, and other issues are discussed here. Read this document before beginning to use the Red Hat Enterprise MRG distributed computing platform.

Chapter 1. System Requirements

This section contains information related to installing Red Hat Enterprise MRG, including hardware and platform requirements.

1.1. Supported Hardware and Platforms

Red Hat Enterprise MRG is highly optimized to run on Red Hat Enterprise Linux 5 and later due to its inclusion of MRG Realtime. The MRG Messaging and MRG Grid capabilities can also run on other platforms, but without the full benefits of running on Red Hat Enterprise Linux 5 and later.

Table 1.1. Supported Hardware and Platforms

Red Hat Enterprise Linux 4.8 Red Hat Enterprise Linux 5.5 Windows
MRG Messaging Native Linux Broker X X
MRG Messaging Client - Java/JMS[a] X X
MRG Messaging Client - C++ X X X
MRG Messaging Client - Python X X X
MRG Messaging Client - Ruby preview X
MRG Grid Scheduler X X
MRG Grid Execute Node X X X
MRG Realtime X
[a] The Java and JMS MRG Messaging Clients are supported for use with Java 1.5 and Java 6 JVMs. For Sun JVMs, it is recommended to use Java 1.5.15 or later or 1.6.06 or later.

1.2. Installing and Configuring Red Hat Enterprise MRG

In order to download and install Red Hat Enterprise MRG 1.3 on your system, you need to subscribe to the appropriate channels on the Red Hat Network (RHN).

Table 1.2. Red Hat Network Channels

Channel Name Platform Architecture
MRG Grid RHEL-4 AS 32bit, 64bit
MRG Grid RHEL-5 Server 32bit, 64bit
MRG Grid RHEL-4 ES 32bit, 64bit
MRG Grid non-Linux 32bit
MRG Grid Execute Node RHEL-4 AS 32bit, 64bit
MRG Grid Execute Node RHEL-5 Server 32bit, 64bit
MRG Grid Execute Node RHEL-4 ES 32bit, 64bit
MRG Management Console RHEL-4 AS 32bit, 64bit
MRG Management Console RHEL-4 ES 32bit, 64bit
MRG Management Console RHEL-5 Server 32bit, 64bit
MRG Messaging RHEL-4 AS 32bit, 64bit
MRG Messaging RHEL-4 ES 32bit, 64bit
MRG Messaging RHEL-5 Server 32bit, 64bit
MRG Messaging non-Linux 32bit
MRG Messaging Base RHEL-4 AS 32bit, 64bit
MRG Messaging Base RHEL-4 ES 32bit, 64bit
MRG Messaging Base RHEL-5 Server 32bit, 64bit
MRG Realtime RHEL-5 Server 32bit, 64bit

Chapter 2. MRG Messaging

2.1. About MRG Messaging

The 1.3 release of MRG Messaging contains several new features and enhancements, including:
  • A new messaging API for both Python and C++
  • Improved mapping from JMS to AMQP, using a new addressing format for destination configuration
  • SASL support for the Python client
  • SASL security layers are now supported in clustering
  • SSL and RDMA addresses can now be included in cluster URLs
  • A new tool for recovering all durable cluster nodes from failure
Installation information for MRG Messaging is available in the MRG Messaging Installation Guide. For use and configuration details, see the MRG Messaging User Guide. For information on developing your own programs for MRG Messaging, start with Programming in Apache Qpid.
Red Hat Enterprise MRG documentation is available for download at the Red Hat Documentation Website.

2.2. MRG Messaging Update Notes

The following is a list of issues to be aware of when upgrading to the 1.3 release of MRG Messaging. This is not a complete list of bugs fixed in this release. For a complete list, please refer to the Red Hat Enterprise MRG Technical Notes for this release.

Table 2.1. MRG Messaging Update Notes

Description Workaround Reference
If global or static variables for qpid::messaging::Session, qpid::messaging::Sender, or qpid::messaging::Receiver go out of scope on application exit after the last qpid::messaging::Connection reference to their containing connection, there is an abort on exit.
Either reset any such global variables before exit or ensure that the order in which those variables are destroyed is such that the connection is destroyed last. This will prevent the abort occurring on exit.
BZ#636186
The Binding URL format used by the JMS client in previous releases has been replaced by a new address format. When upgrading an existing application to use the new Qpid libraries, the old format will not parse correctly by default.
Do one of the following:
  • Use -Dqpid.dest_syntax=BURL to switch the default destination syntax to Binding URL format; or
  • Prefix each destination definition with BURL:. For example: BURL:direct://amq.direct/MyQueue?routingkey='test'.
This ensures that destinations defined using the Binding URL are parsed properly without any error.
Consider using the new addressing scheme from JMS. This is described further in the Programming with Apache Qpid guide.
BZ#634043
Specifying a connection level username on the C++ client when authenticating with the GSSAPI mechanism causes the username to be ignored. Instead, the username for which a kerberos ticket has been obtained will be used. The connection is still authenticated however, so there is no loss of security.
No workaround is possible, but as a valid ticket is required anyway, this in practice has little impact.
BZ#620424
In the 0-10 specific Python client API, the generated classes are now created automatically. Subsequently, the qpid.connection.Connection.spec is no longer required, and has been removed. Consequently, the constructor for that class no longer takes a specification argument.
This is unlikely to have an impact on most applications. Those that do reference the specification can simply remove any such references.
BZ#600256
The definition for the qpid::sys::Duration(AbsTime&) constructor exposed an internal time value from the AbsTime representation which varied between platforms. A time duration can only be calculated as the difference between two points in time, not just one. What the constructor was doing was not portable between platforms.
The definition for the qpid::sys::Duration(AbsTime&) has been removed from the shipped header files and if it has been used it will need to be replaced.
The use of AbsTime and Duration classes are not supported, except where required by other elements of the Qpid client API. However, if an application needs to use this constructor it can be replaced by using the two-argument Duration constructor:
using qpid::sys::Duration;
using qpid::sys::AbsTime;
using qpid::sys::EPOCH;
Duration d(EPOCH, AbsTime::now());
This workaround will allow the constructor to be used between different platforms as expected.
BZ#595788
The use of the failover exchange to keep the list of known brokers in a cluster up to date is no longer automatically part of a connection. The application must explicitly choose that functionality. This was done to avoid the overhead and confusion sometimes caused in situations that did not want or require this.
Existing users of failover will need to modify their code. Previously, the code read:
Connection connection ...
brokers = connection.getKnownBrokers();
This code needs to be changed to read:
Connection connection ...
FailoverListener failoverListener(connection);
brokers = failoverListener.getKnownBrokers();
BZ#531075
When a C++ client processes messages sent by a Python client in which real numbers are included in the headers, the Python client would encode the real numbers as floats. This resulted in lost precision when transferring a message. Real numbers are now encoded as doubles, which restores the lost precision.
No action required
BZ#578538
If the store directory has not been removed from a cluster node prior to restarting, the broker will fail to restart.
Ensure that notice level logging is enabled (this is the default logging option). This will cause the broker to start successfully.
BZ#632188

Chapter 3. MRG Realtime

3.1. About MRG Realtime

Because MRG Realtime provides an updated Linux kernel, it is certified for use on a subset of the hardware systems certified for Red Hat Enterprise Linux. MRG Realtime is certified on x86 and x86_64 architectures only. Red Hat works with hardware vendors to certify systems for use with MRG Realtime based on customer demand. For an updated list of certified systems, see the Red Hat Hardware Catalog.
MRG Realtime is incompatible with the Xen-based virtualization features in Red Hat Enterprise Linux 5 and is not supported for use with any virtualization technology.
The MRG Realtime kernel may be rebased over the lifetime of a Red Hat Enterprise MRG release, however there are no guarantees of a stable kernel Application Binary Interface (kABI) over the life of Red Hat Enterprise MRG.
Installation information for MRG Realtime is available in the MRG Realtime Installation Guide. For information on tuning MRG Realtime, see the MRG Realtime Tuning Guide and the MRG Realtime Reference Guide.
Red Hat Enterprise MRG documentation is available for download at the Red Hat Documentation Website.

3.2. MRG Realtime Update Notes

The following is a list of issues to be aware of when upgrading to the 1.3 release of MRG Realtime. This is not a complete list of bugs fixed in this release. For a complete list, please refer to the Red Hat Enterprise MRG Technical Notes for this release.

Table 3.1. MRG Realtime Update Notes

Description Workaround Reference
The MRG Realtime kernel is newer than the Red Hat Enterprise Linux 5 kernel and contains SELinux components that older policy files cannot recognize. Previous versions of selinux-policy will default to DENY on unknown components, while the new policy files default to ALLOW. This results in MRG Realtime working incorrectly when older SELInux packages are enabled.
Install the selinux-policy packages from the Red Hat Enterprise Linux 5.5 release to ensure that MRG Realtime functions correctly with SELinux enabled.
BZ638299

Chapter 4. MRG Grid

4.1. About MRG Grid

The 1.3 release of MRG Grid contains several new features and enhancements, including:
  • Improved scalability: Run large-scale grids with hundreds or thousands of execution slots, managing millions of jobs.
  • Centralized configuration and management: Manage configuration changes through a central interface and push configuration changes to grid nodes.
  • Enhanced scheduling capabilities: Run low-latency applications by integrating with MRG Messaging, and make use of improved scheduling policies.
  • Integrated virtual machine and cloud usage: Execute jobs on virtual machine execute nodes running KVM, VMWare or Xen, and cloud hosts provided by the Amazon Elastic Compute Cloud (EC2).
Installation and configuration information for MRG Grid is available in the MRG Grid Installation Guide. For use and configuration details, see the MRG Grid User Guide.
Red Hat Enterprise MRG documentation is available for download at the Red Hat Documentation Website.

4.2. MRG Grid Update Notes

The following is a list of issues to be aware of when upgrading to the 1.3 release of MRG Grid. This is not a complete list of bugs fixed in this release. For a complete list, please refer to the Red Hat Enterprise MRG Technical Notes for this release.

Table 4.1. MRG Messaging Known Issues

Description Workaround Reference
The LOCAL_CONFIG_FILE, previously ~condor/condor_config.local, is now located at /etc/condor/config.d/00personal_condor.config. This file should not be edited.
If you modified condor_config.local, save the changes and include them within a new file that you control, such as /etc/condor/config.d/10customized.config.
For comprehensive information about the new configuration file, see the Configuration chapter in the MRG Grid User Guide
BZ#628052
The MRG/EC2 Enhanced AMIs require configuration changes for the feature to work properly.
The MRG Grid configuration on the AMI needs to have the following parameters added:
EC2E_DAEMON_LOG = $(LOG)/CaroniaLog
MAX_EC2E_DAEMON_LOG = 1000000
JOB_HOOKS_LOG = $(LOG)/JobHooksLog
MAX_JOB_HOOKS_LOG = 10000000
Additionally, the following existing configuration:
EC2E_DAEMON = /usr/sbin/caroniad
EC2ENHANCED_HOOK_PREPARE_JOB = $(LIBEXEC)/hooks/hook_prepare_job.py
EC2ENHANCED_HOOK_UPDATE_JOB_INFO = $(LIBEXEC)/hooks/hook_update_job_status.py
EC2ENHANCED_HOOK_JOB_EXIT = $(LIBEXEC)/hooks/hook_job_exit.py
must be changed to read:
EC2E_DAEMON = $(SBIN)/caroniad
EC2ENHANCED_JOB_HOOK_PREPARE_JOB = $(LIBEXEC)/hooks/hook_prepare_job.py
EC2ENHANCED_JOB_HOOK_UPDATE_JOB_INFO =
$(LIBEXEC)/hooks/hook_update_job_status.py
EC2ENHANCED_JOB_HOOK_JOB_EXIT = $(LIBEXEC)/hooks/hook_job_exit.py
These configuration changes will ensure that MRG Grid MRG/EC2 Enhanced will work as expected.
BZ#615140
The Condor daemons now report the year in trace log files. For example:
08/17/10 12:29:06 (pid:2165) ** condor_schedd (CONDOR_SCHEDD) STARTING UP
This is notable for scripts that parse the trace (generally unstructured) log files.
No action required
BZ#628047
When the remote configuration feature installs a new Condor configuration file, it will sometimes restart Condor using the condor_restart command. If changes have been made to the security parameters relating to contacting and controlling the condor_master, a conflict could occur between the new configuration and the existing configuration.
Consequence: If a conflict occurs, condor_restart will fail with the following error message:
"AUTHENTICATE:1003:Failed to authenticate with any method"
If the authentication methods supported by the new configuration and those supported by the old version are disjointed, there will be no way for condor_restart to authenticate itself to the Condor master.
Use one of the following workarounds to resolve this issue:
  • Ensure that the new values for authentication-related parameters are always a superset of the old values. For example, if you wanted to add an encryption method called FOO, you could set it by appending FOO to the old value of SEC_DEFAULT_CRYPTO_METHODS:
    $(SEC_DEFAULT_CRYPTO_METHODS), FOO
  • It is not always possible to append to parameters; for example, you may wish to disable all encryption methods supported in a running Condor pool and replace them with a different method. In this case, temporarily use the appending parameters workaround in one activated configuration, and then activate a different configuration in which SEC_DEFAULT_CRYPTO_METHODS is set to FOO.
  • If necessary, it is always possible to restart Condor manually using the kill command.
This ensures that the error will no longer occur, and authentication will work as expected.
BZ#637200

Chapter 5. MRG Management Console

5.1. About the MRG Management Console

Installation and configuration information for the MRG Management Console is available in the MRG Management Console Installation Guide.
Red Hat Enterprise MRG documentation is available for download at the Red Hat Documentation Website.

5.2. MRG Management Console Update Notes

The following is a list of issues to be aware of when upgrading to the 1.3 release of the MRG Management Console. This is not a complete list of bugs fixed in this release. For a complete list, please refer to the Red Hat Enterprise MRG Technical Notes for this release.

Table 5.1. MRG Management Console Update Notes

Description Workaround Reference
There is a large amount of message traffic that the MRG Management Console needs to process during startup. This can result in a noticeable delay when the MRG Management Console starts up. During this time the various displays are not fully populated and operations from the Console might fail.
This is normal behaviour, and no workaround is required. The delay is difficult to quantify, but it is likely that this startup processing time will increase as the size of the total grid increases. On a typical development grid at Red Hat, it is normal for this startup time to be in the order of a minute or two. Depending on the location of the MRG Management Console host in the overall network topology, this time could be significantly longer.
BZ#634745
The Free Memory and Free Swap numbers reported on the Console Inventory System Overview and Inventory System Detail do not state any measurement units. This is true of the text fields that are displayed as well as the Free Memory graph rulers on the Overview tab. On the graph, numbers on the vertical ruler end in k. This k refers to thousands, not a particular unit of measurement. This might cause confusion for some users.
The graphs measure memory in units of kilobytes. For example, a graph showing free memory of 500k means 500,000 kilobytes. Likewise, a text field showing free memory of 500000 means 500,000 kilobytes.
BZ#634740

Revision History

Revision History
Revision 1-6.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Revision 1-62012-07-18Anthony Towns
Rebuild for Publican 3.0
Revision 1.4-0Thu Oct 7 2010Alison Young
Rebuilt for Publican 2.2
Revision 1.3-0Fri Oct 1 2010Lana Brindley
BZ#637200 - Grid
BZ#632188 - Messaging
Updated Hardware table
Revision 1.2-0Thu Sep 30 2010Lana Brindley
Prepared for publishing
Revision 1.1-0Thu Sep 30 2010Lana Brindley
Updated Hardware table
Added new Messaging features
Some wording changes
Revision 1.0-0Wed Sep 29 2010Lana Brindley
Prepared for publishing
Revision 0.5-0Wed Sep 29 2010Lana Brindley
BZ#638299 - Realtime
Revision 0.4-0Tue Sep 28 2010Lana Brindley
Updated links from redhat.com/docs to docs.redhat.com
Updates from sravish
Revision 0.3-0Mon Sep 27 2010Lana Brindley
Updates from gsim
Updates from bhu
Updates from mattf
Revision 0.2-0Fri Sep 24 2010Lana Brindley
BZ#531075 - Messaging
Revision 0.1-0Thu Sep 23 2010Lana Brindley
BZ#636186 - Messaging
BZ#634043 - Messaging
BZ#620424 - Messaging
BZ#600256 - Messaging
BZ#595788 - Messaging
BZ#578538 - Messaging
BZ#531075 - Messaging
BZ#628052 - Grid
BZ#628047 - Grid
BZ#615140 - Grid
BZ#634745 - Console
BZ#634740 - Console
Revision 0.0-0Tue Sep 21 2009Lana Brindley
Initial document creation