BIND 10 #1634: Abstract pool/lease store: initial requirements list

[BIND 10 Development]

#1634: Abstract pool/lease store: initial requirements list
-------------------------------------+-------------------------------------
                   Reporter:  tomek  |                 Owner:  tomek
                       Type:  task   |                Status:  reviewing
                   Priority:  major  |             Milestone:  Sprint-
                  Component:  dhcp   |  DHCP-20120220
                   Keywords:         |            Resolution:
            Defect Severity:  N/A    |             Sensitive:  0
Feature Depending on Ticket:         |           Sub-Project:  DHCP
        Add Hours to Ticket:  0      |  Estimated Difficulty:  0
                  Internal?:  0      |           Total Hours:  0
-------------------------------------+-------------------------------------

Comment (by tomek):

 Replying to [comment:7 shane]:
 > I haven't looked at Stephen's or Shawn's comments yet, so there may be
 some duplication.
 >
 > First, I think the requirements need an introduction. Something to
 describe what the point of an abstract lease storage is, and how it fits
 into Kea. So, talking about the model of having multiple concrete types of
 lease storage, and so on. It should also discuss the basic functionality
 that lease storage provides, which seems to be both lease storage an pool
 definition according to this document.
 Agree. Wrote a paragraph about reasons for abstract API and a bit of
 background info.

 > From the general requirements, does it make sense to explicitly mention
 that we want both administrative and programmatic (via an externally-
 exposed API) ability to change leases?
 Added M5 requirement, but do we really want to do that? We will get "why
 only leases? My tool needs to change pools/hosts/subnets/whatever as well"
 type of questions really soon. I imagine that many changes will be done
 over b10-cmdctl. We will probably be exposing SQL DB itself, so I'm not
 sure if we need to design API for that.

 > We should probably say what happens when a pool is removed during
 operation. Possibly when one is added too.
 Added question 10 (part of my response to Shawn) about that. Adding pool
 is trivial. We start with pool that has zero leases in it and gradually
 start assigning leases from it. Now that you mentioned it, I just
 remembered that there is a nice feature in Dibbler about pool selection
 that we can use. See question 11.

 > There is nothing in this document about how lease selection works. From
 a requirements level, we need to say if we want there to be alternative
 algorithms for lease selection. I have a vague feeling that we do,
 although we don't in DHCP 4.x so perhaps that is not important. In any
 case, if we decide that we don't want alternative algorithms we should
 also write that down too.
 Good point. Included this in question 11.

 > We should note that although at an abstract level lease and pool
 definitions must support for a wide range of scaling, concrete
 implementations may not. For example, SQLite does not support wide
 parallelism, but is certainly appropriate for smallish servers.
 Clarified that API and concrete implementation support are not the same
 thing.

 > Maybe we also want to note support for really, really small scale sites?
 Like SOHO stuff with <10 devices?
 That's a completely different topic. Few days ago I guys from R&D office
 of Telekomunikacja Polska (largest Polish telecom). They are working on
 CPE and complained that both Dibbler and ISC DHCP are way too large for
 their need, so they picked WIDE implementation. We started talking with
 Stephen what could be done to make Kea really small. One of the options
 would be to implement kind of b10-dhcp4-mini and b10-dhcp6-mini that would
 be stand-alone and not use most of the B10 stuff. It would basically be
 wrappers around libdhcp++. We could also rip features unnecessary in CPE
 environment, like DNS Update (somewhat debatable, but would save quite a
 bit of space), failover, confirm support etc.

 > Finally, I think it might make sense to separate out the requirements
 into:
 >
 >   1. General
 >   1. DHCP
 >   1. DHCPv6
 Requirements for v4 and v6 are really very similar. I proposed a slightly
 different split. See if you like it. If not, please propose a better one.

 > Because it's a bit confusing having them all combined.
 Agree.

 > Now I can look at the other comments and see how much overlap there is.
 :)
 No need to do that. I already did that.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1634#comment:12>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development