Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2022-11-02T15:10:19Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/707wipe script path is wrong.2022-11-02T15:10:19ZFrancis Dupontwipe script path is wrong.Building and running make check from another directory (i.e. using ../configure vs ./configure) I got this warning:
```
wipeCqlData failed:[sh /tmp/kk705/build/../src/share/database/scripts/cql/wipe_data.sh 4.0 -u keatest -p keatest -k k...Building and running make check from another directory (i.e. using ../configure vs ./configure) I got this warning:
```
wipeCqlData failed:[sh /tmp/kk705/build/../src/share/database/scripts/cql/wipe_data.sh 4.0 -u keatest -p keatest -k keatest --request-timeout=6000 2>/dev/null
```
note the file does not exist (i.e. it is at another location):
```
ls /tmp/kk705/build/../src/share/database/scripts/cql/wipe_data.sh
ls: /tmp/kk705/build/../src/share/database/scripts/cql/wipe_data.sh: No such file or directory
```
Not critical as make distcheck does not build databases but anyway should be fixed as it is a bug and it impacts test performances... BTW the create and delete scripts are found so it should not be hard to fix.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/593Consider MySQL CB schema changes to make it compatible with NDBCLUSTER2023-05-10T07:22:33ZMarcin SiodelskiConsider MySQL CB schema changes to make it compatible with NDBCLUSTEROne of the Kea users attempted to use NDBCLUSTER instead of InnoDB engine with Kea 1.5.0. Some CB specific tables added in 1.5.0 use `UPDATE CASCADE` action. Specifically, the tables holding address/prefix pools include `UPDATE` action r...One of the Kea users attempted to use NDBCLUSTER instead of InnoDB engine with Kea 1.5.0. Some CB specific tables added in 1.5.0 use `UPDATE CASCADE` action. Specifically, the tables holding address/prefix pools include `UPDATE` action referencing the subnet_id primary key. This works fine for the InnoDB engine, but not for the NDB cluster.
The NDB cluster docs says this:
```
ON UPDATE CASCADE is not supported when the reference is to the parent table's primary key.
```
And further on it explains:
```
This is because an update of a primary key is implemented as a delete of the old row (containing the old primary key) plus an insert of the new row (with a new primary key). This is not visible to the NDB kernel, which views these two rows as being the same, and thus has no way of knowing that this update should be cascaded.
```
Even though, we use InnoDB by default, we may consider removing the `UPDATE CASCADE` actions on primary keys (which would require us to modify the code that updates subnet_id for a given prefix), to support users which want to play with cluster engines.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/501remote-option4-global-set accepts option with empty data2022-10-24T08:02:55ZWlodzimierz Wencelremote-option4-global-set accepts option with empty data```
{
"arguments": {
"options": [
{
"code": 6
}
],
"remote": {
"type": "mysql"
},
"server-tags": [
"abc"
]
},
"command": "remote-option4-global-set"
}
```
Response:
```
{
"a...```
{
"arguments": {
"options": [
{
"code": 6
}
],
"remote": {
"type": "mysql"
},
"server-tags": [
"abc"
]
},
"command": "remote-option4-global-set"
}
```
Response:
```
{
"arguments": {
"options": [
{
"code": 6,
"space": "dhcp4"
}
]
},
"result": 0,
"text": "DHCPv4 option successfully set."
}
```
Kea should not be configured with empty option. Possible that it's not yet implemented.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/445add support for mongo db2019-02-07T17:00:17ZGhost Useradd support for mongo db---
name: mongodb
about: add mongodb support to kea dhcp server
---
**Some initial questions**
- could not find this request anywhere in issues or on the web
- sure, there are other databases support; but that's not the point
**Is you...---
name: mongodb
about: add mongodb support to kea dhcp server
---
**Some initial questions**
- could not find this request anywhere in issues or on the web
- sure, there are other databases support; but that's not the point
**Is your feature request related to a problem? Please describe.**
- Reduction of the numbers of databases on the client's systems
**Describe the solution you'd like**
- allow kea administrators to configure mongodb in kea
**Describe alternatives you've considered**
- Not really.
**Additional context**
- No.
**Funding its development**
- Sure to some very small degree.
**Participating in development**
- design discussions and testing
**Contacting you**
- Private messages to my gitlab.isc.org registered email address are fine.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/355Postgres unit-tests fail in weird way if postgres timezone is set incorrectly2022-11-02T15:08:42ZTomek MrugalskiPostgres unit-tests fail in weird way if postgres timezone is set incorrectlyI live in Poland (CET, GMT+1), but I was visiting London (GMT) and installed Postgres. It had this in postgresql.conf:
```
datestyle = 'iso, mdy'
timezone = 'GB'
```
However, my system timezone (as set in mac os control panel) was CET....I live in Poland (CET, GMT+1), but I was visiting London (GMT) and installed Postgres. It had this in postgresql.conf:
```
datestyle = 'iso, mdy'
timezone = 'GB'
```
However, my system timezone (as set in mac os control panel) was CET.
This caused weird error in unit-tests:
```
[ RUN ] PgSqlBasicsTest.timeStampTest
NOTICE: table "basics" does not exist, skipping
pgsql_exchange_unittest.cc:896: Failure
Expected: fetched_time
Which is: 1544791527
To be equal to: times[row]
Which is: 1544787927
row: 0
pgsql_exchange_unittest.cc:896: Failure
Expected: fetched_time
Which is: 2147487247
To be equal to: times[row]
Which is: 2147483647
row: 1
pgsql_exchange_unittest.cc:896: Failure
Expected: fetched_time
Which is: 4294970895
To be equal to: times[row]
Which is: 4294967295
row: 2
pgsql_exchange_unittest.cc:896: Failure
Expected: fetched_time
Which is: 1544877927
To be equal to: times[row]
Which is: 1544874327
row: 3
[ FAILED ] PgSqlBasicsTest.timeStampTest (40 ms)
```.
Yes, this was a weird configuration, but Kea should have done both conversions using the same timezone.
At the very least we should print a warning about checking timezone configuration if the values are off by multiplicity of 3600 seconds.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/139lease times stored in localtime in Postgres (DST issue?)2022-11-02T15:08:42ZRay Bellislease times stored in localtime in Postgres (DST issue?)I've observed that lease expiry times appear to be stored in local time in the Postgres database (and perhaps in others?) rather than in UTC.
This might cause unexpected removal of leases from the database at the changeover to or from DST.I've observed that lease expiry times appear to be stored in local time in the Postgres database (and perhaps in others?) rather than in UTC.
This might cause unexpected removal of leases from the database at the changeover to or from DST.backlog