... | ... | @@ -404,7 +404,7 @@ There is little value in trying to support it in BLQ at this juncture. |
|
|
|
|
|
Initially, it looked as though PostgreSQL and MySQL both supported sufficient JSON mechanisms to index and query by JSON. However, further exploration revealed the following:
|
|
|
|
|
|
1. PostgreSQL does support Generalized Inverted (GIN) indexes on JSONB columns, and those mechanisms appear sufficient to address both V4 and V6 needs. However, JSONB columns are not supported until PostgreSQL 9.4. In order to use GIN indexes the user_context column type in the leaseX tables would have to be changed from TEXT to JSONB. This would necessitate changing many of the existing SQL statements in postgresql lease manager. Furthermore, it would mean Kea's PostgreSQL schema could no longer with PostgreSQL pre 9.4.
|
|
|
1. PostgreSQL does support Generalized Inverted (GIN) indexes on JSONB columns, and those mechanisms appear sufficient to address both V4 and V6 needs. However, JSONB columns are not supported until PostgreSQL 9.4. In order to use GIN indexes the user_context column type in the leaseX tables would have to be changed from TEXT to JSONB. This would necessitate changing many of the existing SQL statements in postgresql lease manager. Furthermore, it would mean Kea's PostgreSQL schema could no longer work with PostgreSQL pre 9.4.
|
|
|
2. MySQL does not support indexing on JSON columns at all, in any version. Nor do they seem likely to do so. For indexed queries (i.e not full table scans) would require using generated columns, explicit columns, or a cross-reference table(s).
|
|
|
|
|
|
### V4 solutions
|
... | ... | @@ -431,7 +431,7 @@ Generated columns are automatically calculated on record INSERT and UPDATE, with |
|
|
|
|
|
**PostgreSQL**
|
|
|
|
|
|
Assuming we choose to use JSONB/GIN some examples are select statements are worth exploring. These statements include data that is similar in structure to V6 user-context content and uses a JSONB boolean expression similar to what we would employ for BLQ. The followings statement returns true (t):
|
|
|
Assuming we choose to use JSONB/GIN some examples of select statements are worth exploring. These statements include data that is similar in structure to V6 user-context content and uses a JSONB boolean expression similar to what we would employ for BLQ. The following statement returns true (t):
|
|
|
|
|
|
```
|
|
|
select '{ "relay-info":[ { "remote-id":10, "hop":1 }, { "remote-id":20, "hop":2 }]}'::jsonb @> '{"relay-info":[{"remote-id":20}]}'::jsonb;
|
... | ... | @@ -508,7 +508,7 @@ Current Lease Query hook library config has a single parameter, `requesters` whi |
|
|
"active-query-enabled" : false,
|
|
|
|
|
|
"lease-query-ip": "127.0.0.1",
|
|
|
"lease-query-port": 67,
|
|
|
"lease-query-tcp-port": 67,
|
|
|
|
|
|
"max-requester-connections" : 10,
|
|
|
"max-concurrent-queries": 4
|
... | ... | @@ -544,7 +544,7 @@ The TLS parameters are self-explanatory. |
|
|
|
|
|
RFC 6926/Sec 6.2.7, talks about lease states of "available" or "remote" when they are unassigned based upon whether or not they are currently in scope for (i.e. held by) the server responding to the LeaseQuery.
|
|
|
|
|
|
Unlike ISC DHCP, Kea does track which server in an HA configuration currently holds a free lease, nor is there an efficient way for a server to know if such a lease is in the server's scope, outside of the HA hook library. One avenue to consider would be to store the server-id of the server making the lease state change in the user-context. Servers responding the a bulk lease query could toggle local/remote based on whether or not it matches the lease's server-id. Since this differentiation in state is not required by the RFC, Kea will not be implementing it as this time.
|
|
|
Unlike ISC DHCP, Kea does track which server in an HA configuration currently holds a free lease, nor is there an efficient way for a server to know if such a lease is in the server's scope, outside of the HA hook library. One avenue to consider would be to store the server-id of the server making the lease state change in the user-context. Servers responding the bulk lease query could toggle local/remote based on whether or not it matches the lease's server-id. Since this differentiation in state is not required by the RFC, Kea will not be implementing it as this time.
|
|
|
|
|
|
### Lease Store Concurrency
|
|
|
|
... | ... | @@ -587,4 +587,6 @@ A very preliminary task break down is shown below: |
|
|
3.1 Add callouts as needed
|
|
|
3.2 Extend configuration parsing
|
|
|
3.4 Instantiate LeaseQueryListener (when enabled)
|
|
|
``` |
|
|
\ No newline at end of file |
|
|
```
|
|
|
|
|
|
|