This site best when viewed with a modern standards-compliant browser. We recommend Firefox Get Firefox!.

Linux-HA project logo
Providing Open Source High-Availability Software for Linux and other OSes since 1999.

USA Flag UK Flag

Japanese Flag

Homepage

About Us

Contact Us

Legal Info

How To Contribute

Security Issues

This web page is no longer maintained. Information presented here exists only to avoid breaking historical links.
The Project stays maintained, and lives on: see the Linux-HA Reference Documentation.
To get rid of this notice, you may want to browse the old wiki instead.

1 February 2010 Hearbeat 3.0.2 released see the Release Notes

18 January 2009 Pacemaker 1.0.7 released see the Release Notes

16 November 2009 LINBIT new Heartbeat Steward see the Announcement

Last site update:
2018-06-20 18:25:39

18) This issue was raised by SunJiangDong. He need the clarification about the format of command-line parameters transferred to LRM from CRM. Besides, need to tranfer the environment parameters to LRM separately from command-line parameters, for example,don't merge them in one ghashtable.

  • More considerations will come...
  • AlanRobertson replies: I don't quite know what you mean by command line parameters transferred to the CRM from the LRM. Since the CRM won't start up (or invoke) the LRM, it won't be possible to pass command-line parameters to the LRM from the CRM, and the LRM won't inherit it's environment from the CRM either. Are you referring to environment parameters passed as part of the API?

    AndrewBeekhof chimes in: We had this chat yesterday on IRC and I believe SunJiangDong is speaking of InstanceParameters. It was agreed that InstanceParameters would be passed to the LRM in a HashTable of the form ("param_name", "value"). The LRM, based on the type of the RA would convert this into a compatible form (ie. --param_name=value, or param_name=value as an environment variable, or any other approproate form). It was seen that this was a job for the LRM as it would require the CRM to know too much about a the internals of a resource.