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

[BIND 10 Development]

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

 * status:  reviewing => closed
 * resolution:   => complete


Comment:

 I made some minor changes to the formatting to make it clearer.  Also, in
 the "DB Information" section I took out references to tables so that it
 now states what information needs to be stored for each entity. (Depending
 on how much we normalize the database, one or more tables may be needed
 for each category of information.)

 > Added as suggested, but that is somewhat difficult, e.g. sqlite blocks
 if more than one concurrent write is performed.
 I think that is only if there are concurrent writes to the same table;
 concurrent writes to different tables are allowed.  (Although admittedly
 the common case is that multiple processes will want to write to the same
 table.)

 > I think we should not be vague any more regarding actual DB layout. I
 think it is a right time to start concrete DB layout design (i.e. tables,
 fields and relations).
 Agreed, but let's put that in a separate design document.  Otherwise there
 is a danger that we skew requirements to the design we have in mind.

 >> Do we want to store additional flags relating to pools, such as:
 > I was more thinking about using hooks for that.
 Hooks will be OK, providing that as part of the DHCP delivery we supply
 hook code for the common cases.  At the last DHCP meeting we came to the
 conclusion that a lot of the stuff we now do in the configuration file can
 be done in hooks, and that is true. However, it will be easier for users
 if we supply some hooks to cover common cases.

 >> The more general question though is whether we want some form of pool
 hierarchy with the ability to associate attributes with any level of the
 hierarchy and with the resulting set of attributes for an address
 determined from the attributes at its level and those above it.
 > No. One of the reasons we are rethinking configuration is to get rid of
 complexity, not exchange one complexity to another.
 Well, at some point we will need to associate attributes with items, and
 we need to get clear in our own minds what is needed.

 > My understanding is that Stephen suggested to use binary form and
 convert it to human form only if needed (e.g. to log if logging is
 enabled).
 That was the idea.

 One final thing: looking through the requirements, we must ensure that the
 design clearly identifies what will be in the lease database and what will
 be in the configuration database.  We also need to be very clear - perhaps
 by writing explicit use-cases - how we set up the system to support common
 configurations.  That way we will be able to check that the proposed
 design will work.

 I'm closing the ticket because I think we have got as far as we can with
 the requirements at this stage.  We can re-open it (or open another one)
 if we need to alter them in any significant way.

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