Opened 2 years ago

Closed 22 months ago

#5467 closed enhancement (complete)

HA: Database fetching and synchronization (v6)

Reported by: tomek Owned by: marcin
Priority: medium Milestone: Kea1.4
Component: high-availability Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no


HADesign uses database fetching and synchronization. There are two aspects of this mechanism:

  • "client" side, where the server is able to send a request to its partner to retrieve all leases and then properly process responses and update its own local database. This is covered by this (#5467) ticket.
  • "server" side, where the server is requested by its partner to provide its leases. This covers going through its own database and sending all (or selected) leases. This is covered by #5469 ticket.

This ticket is about v6 aspect of the client-side. For v4 counter-part, see #5466.


Change History (7)

comment:1 Changed 22 months ago by marcin

  • Owner set to marcin
  • Status changed from new to accepted

comment:2 Changed 22 months ago by marcin

  • Owner changed from marcin to UnAssigned
  • Status changed from accepted to reviewing

The code is now ready for review. The 'trac5467' is stacked on the 'trac5460' branch which is to be reviewed as part of #5460.

Proposed ChangeLog entry:

XX.	[func]		marcin
	Implemented IPv6 lease database synchronization in HA hook
	(Trac #5467, git cafe)

comment:3 Changed 22 months ago by tmark

  • Owner changed from UnAssigned to tmark

comment:4 Changed 22 months ago by tmark

  • Owner changed from tmark to marcin

I fixed a typo so please pull first. The code looks good, unit test pass under Ubuntu 16.04.
I really only have one issue:

In TEST_F(HAServiceTest, asyncSyncLeases) and TEST_F(HAServiceTest, asyncSyncLeases6), there
isn't exactly an explicit test of an update being rejected because it is stale. On the one hand
you can argue that because the cltts match, no unexpected updates were done as you only modified
the cltt of the first lease. On the other hand, that would actually still be true even if all of
the updates were done wouldn't it?

I'm think you may need to modify a field in one of the lease's and then verify that the fields do
not match after the sync. This would explicitly verify the update was rejected.

Either that or you could parse the log output for stale update messages. I ran the tests with logging output to make sure they were occurring but this seems like more work to me ;).

comment:5 Changed 22 months ago by marcin

  • Owner changed from marcin to tmark

I addressed your comments, I hope. Ready for re-review.

comment:6 Changed 22 months ago by tmark

  • Owner changed from tmark to marcin

Changes are fine. I fixed up the wording a little, so please pull first, then merge.

comment:7 Changed 22 months ago by marcin

  • Resolution set to complete
  • Status changed from reviewing to closed

Merged with commit bedfe4b446f20942fb931715fcd5c7671ea5b949

Note: See TracTickets for help on using tickets.