The following are the minimal requirements for submitting CRM bug reports. Initiative is always appreciated... perhaps take a guess at what might be wrong or a possible solution.

By observing these guidelines the chances of your problem being fixed and fixed quickly are greatly increased. It also helps to increase my productivity which is important as I am somwhat of a bottleneck at the moment.

NOTE: I may request code fragments below... if you are using a binary distribution, please indicate the exact version you found the bug in. If the version you have does not exist in the version list, please indicate it in the summary and open another bug about the missing version number.

Pre-checks

1. Can you reproduce the problem with the latest code in CVS (If not using an official release)

2. Has the bug already been reported in HeartbeatBugzilla If so:

   1. do not open a new report
   2. if the bug is marked closed, did you try a later version?

   3. re-open the bug if it was closed and your version is later than the reported fix

   4. only add your information if it differs from the existing report
   5. Send me an email if it looks like I'm not doing anything about it
3. If the problem relates to one of the Xnode.sh scripts, please check if it fits into one of the other categories first.
4. If the problem involves a segfault, please ensure that the segfault is being caused by the CRM and not common Heartbeat code.

   Feel free to CC me on these bugs however - just clearly indicate that the bug is not actually _in_ the CRM

Types of bugs and the required information

1. If the bug involves an CRM_ASSERT or CRM_DEV_ASSERT being triggered:
   1. The summary should clearly indicate:
      1. The bug relates to an assert
      2. The CRM component in which the assert was triggered

      3. Where possible a couple of words regarding what the assert is testing
         Where the assert is called with FALSE, describe the if-statement it is found in
         Example CIB: Assert triggered in cib_process_erase()

   2. A stack trace from the associated core dump
   3. The name of the function the assert was in
   4. 5 lines before and including the assert (just in case the code has changed)

   5. The last 20 lines of logging from only the process in which the assert was triggered

   6. If the bug was found while running a specific test, please indicate this
2. Otherwise if the bug involves a core file:
   1. The summary should clearly indicate
      1. The bug relates to segfault
      2. The CRM component which segfaulted

      3. The name of the CRM function being called at the time
         Example CIB: Segfault in cib_process_erase()

   2. A stack trace from the associated core dump
   3. The name of the function the assert was in
   4. 5 lines before and including the first occurance of CRM code in the stack (just in case the code has changed)
   5. The contents of variables being used on the line of the first occurance of CRM code in the stack

      1. Use print *variable for pointers

   6. The last 20 lines of logging from only the process that segfaulted

   7. If the bug was found while running a specific test, please indicate this
3. If the bug involves an assert in Xnode.sh failing:
   1. The summary should clearly indicate
      1. The script the bug relates to

      2. A couple of words regarding what the assert is testing and where in the test it was
         Example 2node.sh : rsc2 not moved to test_node_2 after startup

   2. The contents of error.txt in the test directory
   3. The contents of the test directory as an attachment
4. If the bug is occured in a CTS run, please provide these additionally:
   1. In which cts test the bug is occured
   2. The command line to start the CTS
   3. The whole output of CTS's run, be sure you include the Random seed.
   4. The combined logs from the test monitor machine.But, if it's too long to upload to bugzilla, only include the last few dozen lines inline in the report.
   5. the content in the test directory on monitor node you are using ( -D paramter or /etc/ha.d/ for default)
5. If you believe there is a logic error in the CRM:
   1. The summary should clearly indicate
      1. The report refers to a logic error
      2. The CRM component the bug relates to

      3. The type of behaviour that is incorrect
         Example: PolicyEngine : Logic error in placement of incarnation resources

   2. What the observed behaviour is
   3. How you observed the behaviour Eg. By running crmadmin, by looking at cib.cml, etc.
   4. How to replicate that behaviour
   5. What you believe the correct should be
   6. Anything else that might seem relevant (eg. source code, logs, other output)

Linux-HA site built by the Linux-HA crowd. HTML4 / CSS2