Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Kea Kea
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 505
    • Issues 505
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 56
    • Merge requests 56
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • KeaKea
  • Issues
  • #1230

Closed
Open
Created May 12, 2020 by Tomek Mrugalski@tomek🛰Owner

design for Incremental lease retrieval

There's a need in Stork to be able to retrieve incremental lease updates. The goal here is to be able to get the state of all leases once during Stork start-up and then somehow be able to retrieve only incremental updates.

There are several ways how this could potentially be implemented:

  1. we could use HA backup server functionality - Stork would configure itself as backup server and would receive updates as they appear. The benefit with this approach is less signalling when there's little traffic. Another benefit is that the update would become visible almost immediately. The downside is that if Stork becomes unavailable for some time (being restarted, system reboots etc), it would potentially miss some updates.
  2. an alternative apprach is to implement lease-get-all-since or lease-get-recent, a new command that would retrieve only leases updated after certain timestamp. We already have the info in lease DB, we would have to implement a new query to retrieve it. This has the advantage of always getting all the leases. The downside is that we'd have to implement more (this should work for all backends). Also, this has a potential to be more distruptive for Kea (or more precisely the disruption would be more concentrated in discrete event rather than spread out as in the proposal 1).

Need to handle deleted leases as well.

Edited Jul 21, 2020 by Tomek Mrugalski
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking