BIND 10 #2238: Pool/Lease Configuration - IPv6

[BIND 10 Development]

#2238: Pool/Lease Configuration - IPv6
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  stephen
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:  Sprint-
                   Priority:         |  DHCP-20121004
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  dhcpconf                           |           Sub-Project:  DHCP
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by tomek):

 * owner:  tomek => stephen


Comment:

 Replying to [comment:7 stephen]:
 > '''Response to 'Things to consider' in comment:2'''
 > > this ticket covers configuration storage only. It is intended to store
 v6 server configuration. The actual configuration parser (that translates
 user's configuration into structures defined) is part of a separate
 ticket, see #2269.
 > One of the comments above suggests separate CfgMgr4 and CfgMgr6 classes.
 Let's keep them unified for now. If the code becomes too big, we will
 split them.

 > > Currently classes Pool, Pool6, Subnet, Subnet6 are stored in the same
 files as !CfgMgr?. As they are part of the !CfgMgr?, they may be possibly
 defined as internal classes (e.g. CfgMgr::Pool, rather than just a Pool).
 Alternatively, they could be moved to separate files. Finally, they can be
 left as they are now.
 > As noted above, I suggest moving them to separate files.  The files are
 smaller to edit, and the name of the file clearly indicates the contents.
 Done. pool.{cc|h}, subnet.{cc|h} and triplet.h were created.

 > > If would be nice if Pool and Subnet were abstract classes.
 Unfortunately, I couldn't find any method that would be required in both
 derived versions (Pool4 and Pool6) and take a parameter that is common for
 both derived classes.
 > The identification of the pool/subnet could be handled in a base class.
 Also, utility functions such as an address being in a given range,
 checking that "first < last", etc.
 By identification you mean getID() method? It is already in the base class
 (Pool). I will probably move some methods to base class once I'll work on
 #2237 (v4 pool/subnet storage).

 > > I'm not sure if pointers to Pool and Subnet are really needed. I would
 like to hear reviewer's opinion on that.
 > Leave the definitions in for now.  If it turns out that they are not
 used, they can always be removed (or moved to the test files where they
 are used).
 Ok.

 > > Parameter inheritance is planned to be implemented as part of the
 configuration parser logic and the inheritance will be done at
 configuration phase. That means that Subnet6 objects will be instantiated
 with their "ultimate" values with inheritance already applied if
 necessary. That will make configuration phase slightly slower, but will
 make the actual operation faster.
 > See comments above.  The overhead of splitting the global/specific
 parameters when accessing the values is only a few instructions (probably
 just one "if" if the accessor functions are inline).  Opposed to this is
 more complicated parser logic (and reconfiguration logic) if objects are
 instantiated with their "ultimate" values.
 Ok. I will see how this unfolds when I implement configuration parser.
 There's another complication here - the default values defined in spec
 files. I'm not sure how they affect the problem. I will give it more
 thought during #2269 work.

 That hopefully answers all comments. Please review.

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