Description of problem: The customers applications that use LSF cluster id's expect a maximum cluster id of 9999999 and their types are set up for that. They would like to limit the maximum cluster id in condor to never exceed 9999999, where the cluster id rolls back over to a minimum value.
Added new parameter SCHEDD_CLUSTER_MAXIMUM_VALUE. Default is 0 (no max).
I've tested this issue on RHEL 5.5/4.8 x i386/x86_64 with QMF/condor_submit/SOAP. Submitting over low-latency has no meaning. Basic feature functionality works. --> VERIFIED
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, applications that use LSF cluster id's expected a maximum cluster id of 9999999 and their types were set up for this maximum. This update adds the new parameter SCHEDD_CLUSTER_MAXIMUM_VALUE, which is by default set to 0 and not to the maximum.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Previously, applications that use LSF cluster id's expected a maximum cluster id of 9999999 and their types were set up for this maximum. This update adds the new parameter SCHEDD_CLUSTER_MAXIMUM_VALUE, which is by default set to 0 and not to the maximum.+This update adds the new parameter SCHEDD_CLUSTER_MAXIMUM_VALUE, with which the maximum value of cluster id. default is set to 0, which means the value of the cluster id is unbounded.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -This update adds the new parameter SCHEDD_CLUSTER_MAXIMUM_VALUE, with which the maximum value of cluster id. default is set to 0, which means the value of the cluster id is unbounded.+This update adds the new parameter SCHEDD_CLUSTER_MAXIMUM_VALUE, with which the maximum value of cluster id. default is set to 0. This means that value of the cluster id is unbounded.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -This update adds the new parameter SCHEDD_CLUSTER_MAXIMUM_VALUE, with which the maximum value of cluster id. default is set to 0. This means that value of the cluster id is unbounded.+This update adds the new parameter SCHEDD_CLUSTER_MAXIMUM_VALUE, which sets the maximum value of the cluster ID. The parameter defaults to 0, which results in the cluster id being unbounded.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -This update adds the new parameter SCHEDD_CLUSTER_MAXIMUM_VALUE, which sets the maximum value of the cluster ID. The parameter defaults to 0, which results in the cluster id being unbounded.+This update adds the new parameter SCHEDD_CLUSTER_MAXIMUM_VALUE, which sets the maximum value of the cluster ID. The parameter defaults to 0, which results in the cluster ID being unbounded.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0773.html