Static leases, host reservation proposal

[Stephen Morris]

On 23/06/2014 18:56, Tomek Mrugalski wrote:

> Depending on the size of the deployment, solution to a) gravitates 
> towards one of the opposing approaches. For small deployments,
> admins typically prefer to add extra clauses to the config file.
> That is more convenient if you're talking about tens, maybe up to
> 100 hosts.
> 
> On the other hand, larger deployments that count their clients in 
> thousands or more, typically would prefer to keep that information
> in a database. They also typically do not store anything besides
> some sort of client identifying information (usually MAC) and a
> reserved IP address.

Do both.

Use the database.  But to make things simple for for small sites, if
the configuration specifies a "fixed host" file, copy the file into
the database when the configuration is read.

> Option 2. Another possible approach is that we can keep the host 
> reservations in the database. The change isn't that difficult. We
> could extend current definition with an additional column (bool
> fixed_lease), tweak the code to honour it (e.g. don't remove the
> lease when it expires or is released by the client) and it would be
> ready to be used. That would have the same characteristic as other
> data we keep in the databases: ability to update it using third
> party tools, no need for restart, instant application, not possible
> to cause inconsistency (i.e. the DB itself enforces addresses to be
> unique). On the downside, this offers less flexibility, because you
> wouldn't be able to specify extra options or have just MAC-hostname
> reservations.

Instead of making that column a bool, you could make it a pointer into
another table holding the options.  A NULL value would indicate that
it is a dynamic lease.

> Also, it would be somewhat confusing as you'd keep current active
> leases (devices that are currently active in your network) and info
> about reserved devices (all networks known in your network) in the
> same table. They would just differ by a single column.

Not really. If there was really a pressing need to distinguish between
the two at a high level, we could create views: one view displays
fixed leases, the other dynamic leases.

> On the other hand, it would be trivially easy to say that the
> address that was assigned should now be reserved for specific
> client. Just flip a bit in the database and you're done. Don't want
> it to be reserved anymore? No problem, just flip the big again and 
> the server will recycle the lease.

Or just delete it from the table.

> None of those options is vastly superior to the other and I think
> we will eventually need to implement both. The question here are:
> which one to implement first and whether we want to implement the
> second one in the 0.9.1 timeframe (or before 1.0).

The idea of constantly rewriting the configuration file to add and
remove fixed hosts (especially if there are tens of thousands of them)
is very clumsy so, if we are aiming for Kea to be used in big
installations, I think we need to go the database route.  Any large
installation is likely to have its information in a database anyway;
it would be natural for such a site to use the same database software
for Kea backend as they use for their inventory systems, and to modify
the latter to add and remove fixed host information in the former.

So I would say do the database first, and write the host file ->
database conversion program later.

Stephen