Adar Dembo created KUDU-2718:
--------------------------------
Summary: master_failover-itest when HMS is enabled is flaky
Key: KUDU-2718
URL: https://issues.apache.org/jira/browse/KUDU-2718
Project: Kudu
Issue Type: Bug
Components: test
Affects Versions: 1.9.0
Reporter: Adar Dembo
Attachments: master_failover-itest.1.txt
This was a failure in
HmsConfigurations/MasterFailoverTest.TestDeleteTableSync/1, where GetParam() =
2, but it's likely possible in every multi-master test with HMS integration
enabled.
It looks like there was a leader master election at the time that the client
tried to create the table being tested. The master managed to create the table
in HMS, but then there was a failure replicating in Raft because another master
was elected leader. So the client retried the request on a different master,
but the HMS piece of CreateTable failed because the HMS already knew about the
table.
Thing is, there's code to roll back the HMS table creation if this happens, so
I don't see why the retried CreateTable failed at the HMS with "table already
exists". Perhaps this is a case where even though we succeeded in dropping the
table from HMS, it doesn't reflect that immediately?
I'm attaching the full log.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
