[kea-dev] Design for Kea Host Reservation

Marcin Siodelski marcin at isc.org
Mon Oct 6 17:54:32 UTC 2014



On 06/10/14 18:29, Tomek Mrugalski wrote:
> On 06.10.2014 15:55, Marcin Siodelski wrote:
>> On 01/10/14 20:52, Tomek Mrugalski wrote:
>>> On 30.09.2014 13:20, Marcin Siodelski wrote:
>>>> I have created a new design document on Kea wiki:
>>>> http://kea.isc.org/wiki/HostReservationDesign for Host Reservation.
>>> Here are my comments. I like the design a lot. I think it will address
>>> our needs. We will probably tweak it a little bit over time, but it a
>>> very solid proposal. Here are my comments:
>>>
>>> Information stored for HR section
>>> IP address(es) - should mention that list is for IPv6 only, v4 need a
>>> single address only. There's no need to reserve more than one IPv4
>>> address. Also, please explicitly say that IP means IPv4 and IPv6.
>>>
>>> Temporary addresses. We do not support temporary addresses at all and
>>> in a sane environment, there is no requirement to reserve them in any
>>> way. On the contrary, it should be an explicit non-requirement. We
>>> should probably state that somewhere in the design (and hope that odd
>>> users wanting their temporaries to be static will never appear :)
>>>
>>> We should add that currently there is no way to define what options
>>> can be sent for a given class. This capability will be added in the
>>> future.
>>>
>>> I'd love to see DUID reservation example for DHCPv4.
>>>
>>> I like the paragraph explaining what the prefixes (dhcp_, dhcp4_ etc.)
>>> mean. This is sort of intuitive, but it's nice to have it explicitly
>>> stated.
>>>
>>> Shouldn't host_id and reservation_id be of type primary key? The diagram
>>> in MySQL database schema suggests it is a simple int. I'm not a
>>> MySQL expert, so this is an honest question. I think that setting a
>>> field to primary key type introduces three things: first, it is being
>>> assigned automatically during inserts. Second, the next value is being
>>> stored and applied automatically (autoincrement). Third, a unique
>>> restriction is added.
>>
>> Yes, they are supposed to be primary key. I don't know why the SQL has
>> been generated without them being primary keys.
> Host_id, option_id (in 2 tables) and reservation_id fields still may
> contains non-unique values. NOT NULL and AUTO_INCREMENT are fine, just
> something about values being unique is missing.

There is no need for this because there is are primary keys associated
with these columns which implicates that they are unique.

> 
>>> I'm a total MySQL noob, so forgive my ignorance, but why do we need
>>> ALLOW_INVALID_DATES? MySQL does not simply insert invalid dates, and
>>> sort of sanitizes it to zeros. MySQL doc
>>> (http://dev.mysql.com/doc/refman/5.5/en/sql-mode.html, also applies to
>>> older versions) says that invalid date of 2014-04-31 will be sanitized
>>> to 0000-00-00.
>>
>> I don't have strong opinion here. In fact, the database schema doesn't
>> use any time values at the moment. So, having this one way or another
> Huh? What about expire in lease4 and lease6? If a user decides to keep
> both hosts and leases (a common assumption, I suppose), then it will
> affect the leases data.

Ok. That is convincing.

> 
>> doesn't hurt. The reason why it is set to this value is that the MySQL
>> workbench tends to inject this into the generated SQL. How about we
>> revisit this if we introduce some time/date columns to the database?
> No, let's not add something we don't need. It's cleaner approach.
> 

Ok. I'll remove this.

Marcin


More information about the kea-dev mailing list