Wait option no longer honored reliably about crmsh HOT 9 CLOSED

It sounds like there might be a bug, yes. I will investigate.

from crmsh.

Well, crmsh hasn't changed in this aspect from what I can tell.. did you upgrade pacemaker as well as crmsh?

from crmsh.

Yes, previously I used 1.1.10, with the new crmsh I'm on 1.1.12.

from crmsh.

On Thu, Mar 12, 2015 at 06:31:52AM -0700, omgold wrote:

Yes, previously I used 1.1.10, with the new crmsh I'm on 1.1.12.

Essentially, the wait option makes crmsh wait for the pacemaker
DC to get back into the IDLE state.

Perhaps something changed in the meantime in pacemaker.

Does crmsh immediately return?

Could you also provide a hb_report (or crm_report) when crmsh
doesn't behave as expected? If you can easily reproduce, then run
crm with -dR and provide that output too.

from crmsh.

In fact, right now I have trouble reproducing on the fly. I get it more or less consistently on a fresh system, when trying it for the first time (I have an automated testing setup, which shows this behavior). So the problem definitely exists, but it seems to take me time to look into that. I will send you a crm_report as soon as I can get one.

from crmsh.

Okay, now got a crm_report for you, but I cannot attach it here. Where should I send it to?

Two more interesting facts:

• it also doesn't happen with old crmsh on pacemaker 1.1.10, so the
  problem seems to be with crmsh
• it seems to need some long chains of order constraints, so the
  failover will take time

from crmsh.

Did some search myself in the crmsh code. It seems when I try the command above wait4dc() is actually called and the found state is immediately S_IDLE. I tried adding an extra delay there before the first check. This shows, though, that the actually change of the stickiness does not happen before the wait4dc returns. So it is no surprise at all that the state is still idle. The call to wait4dc seems to come from Context.execute_command(), which looks okay to me. So I don't understand why the wait is before the change of stickiness.

from crmsh.

Thanks, that made it click for me! I've figured out what the problem is now. I just need to work out a fix.

from crmsh.

The above commit should fix the problem. execute_command() was actually the wrong place to wait, since the actual CIB commit happens after the command to modify the CIB was executed. I accidentally created this bug when I reworked the UI code between 1.2 and 2.0. Need to figure out some way to create a reliable test case for this.. Thanks for reporting it!

from crmsh.