MAX_CONFIGURED_PACKAGES in cluster config not honoured.

[sc_dodc_be]

Dear all,

I've been fooling around with Serviceguard for some time now and no matter what I do, I can't seem to get SG to respect the MAX_CONFIGURED_PACKAGES parameter, it always defaults to 300.

How do I change this? Is this perhaps overridden in a file somewhere else?

Regards,

Wim Cossement

[melvyn burnard]

Each version of Serviceguard has a DEFAULT value for that variable. If you are getting a value of 300, then you are using Serviceguard A.11.19, and as before, this is the DEFAULT value. If you wish to change it, edit the cluster ascii configuration file, either before creating the cluster, or once the cluster is configured and running, and then cmapplyconf to put the required value into the running binary.

[sc_dodc_be]

Hi Melvyn,

I know how to change and apply cluster parameters and my ascii config file has been modified to 100 as the maximum number of packages but when I check or apply it I always get a statement:

Defaulting MAX_CONFIGURED_PACKAGES to 300.

So it's in my file but the cluster kinda ignores it.

Wim

[melvyn burnard]

interesting. Sounds like this MAY be a bug, but I have not seen that.
I have configyuured a couple of these clusters, and set the variable to 10 or even 20, with no problem.
Perhaps log a call with the Response Centre?#

[John Bigg · Accepted solution]

No bug, this parameter is effectively obsolete. The memory used to be allocated as needed, but things have been re-structured and enough memory for 300 is always available now and this parameter effectively does nothing. It is simply there for compatibility with old ascii files. From the 11.17 release notes:

The memory allocation for packages has changed. When you create
the cluster, Serviceguard now reserves enough memory for the
maximum number of packages supported. Previously, it allocated
memory based on the value of MAX_CONFIGURED_PACKAGES
that was specified in the configuration file.

[sc_dodc_be]

Damn, this kinda solves the case!

Too bad they don't specify this !in the config file, that contains tons of comments, that this parameter is obsolete though it's required.

But in the meantime I've opened a case with HP, I'm going to wait and see what they say.

Thanks,

Wimmy

[John Bigg]

Well, according to some tests by Melvyn, it appears that this limit seems to be artificially imposed if you do lower the limit with the parameter even if cmcld does not care and need to allocate more memory. So, it does appear something strange is going on in your case.

If support cannot work it out it will probably end up with me anyway :-)

[sc_dodc_be]

HP support more or less told me this:

We're still trying to find out why this changed.
All we know is that this became a dynamic parameter from version 17 that can be adjusted.
We don't know why this is and there is almost no info that can be found in the Release notes.
And apparently that you, John, are an HP engineer... :-)

So they suggest to close the case.

As satisfying as this explanation might be for me I still consider it a bit sloppy to do such a thing.

It's like: please fill in this form that we will ignore anyway! :-p

[Stephen Doud]

I performed a test on my A.11.19 cluster:

# Package Configuration Parameters.
# Enter the maximum number of packages which will be configured in the cluster.
# You can not add packages beyond this limit.
# This parameter is required.
MAX_CONFIGURED_PACKAGES 30


$ cmapplyconf -f -C CLS.sux12
Defaulting MAX_CONFIGURED_PACKAGES to 300.
Defaulting MAX_CONFIGURED_PACKAGES to 300.
Modifying configuration on node sux1
Modifying configuration on node sux2
Completed the cluster creation

Notice that it indicates that it defaults to 300 packages, however, inspecting the cluster binary:

$ cmviewconf | grep -i max
maximum configured packages: 30

I submitted a change request to the lab to deal with the inaccurate cmapplyconf messages and perhaps remove the parameter from the cluster ASCII file entirely.

However, as John said, there is no longer necessity to change the value from default of 300, as it doesn't reduce system resource usage.

[sc_dodc_be]

Good news, I've gotten HP to the point where they recognise this as a defect (QXCR1000980236) and will provide a patch around 15 January 2010.

So I can close this tread, thanks for all the replys!