Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-22T13:05:49Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2957dhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on...2024-03-22T13:05:49ZJohn W. O'Briendhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on dhcp6_server table---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the b...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the behavior:
1. Initialize a PostgreSQL database using dhcpdb_create.pgsql
2. Inspect the dhcp4_server_modification_ts index
3. See that it is associated with the dhcp6_server table
**Expected behavior**
A clear and concise description of what you expected to happen:
The dhcp4_server_modification_ts index should be associated with the dhcp4_server table.
**Environment:**
- Kea version: 2.2.0
- OS: FreeBSD 13.2-RELEASE amd64
- Compiled with pgsql backend
- Loaded hooks: pgsql_cb
**Additional Information**
```
kea=> \di dhcp4_server_modification_ts
List of relations
Schema | Name | Type | Owner | Table
--------+------------------------------+-------+-------+--------------
public | dhcp4_server_modification_ts | index | kea | dhcp6_server
(1 row)
```
This appears to have been introduced as a [copy/paste error in version 7.0 of the schema](https://gitlab.isc.org/isc-projects/kea/-/blob/Kea-2.3.8/src/share/database/scripts/pgsql/dhcpdb_create.pgsql#L1398). I could identify no correspond bug in the MySQL schema.
**Contacting you**
* SMS/Signal: (available upon request)
* GitHub/GitLab: neirbowj
* Mastodon: [@neirbowj@mastodon.online](https://mastodon.online/@neirbowj)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2773Update doc for PostgreSQL >= 152023-07-05T10:39:18ZFrancis DupontUpdate doc for PostgreSQL >= 15PostgreSQL >= 15 requires extra commands to grant permissions for things e.g. tables inside databases. The documentation should be updated so admins can use recent versions of PostgreSQL using only Kea docs (vs having to googling...).PostgreSQL >= 15 requires extra commands to grant permissions for things e.g. tables inside databases. The documentation should be updated so admins can use recent versions of PostgreSQL using only Kea docs (vs having to googling...).next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2479Documentation - upgrading Kea servers with a common DB backend2023-07-31T13:34:54ZPeter DaviesDocumentation - upgrading Kea servers with a common DB backend**Documentation - upgrading Kea servers with a common DB backend**
Kea implementations where servers do not share common databases Kea may be upgraded individually.
In this way the down time of dhcp services may be limited.
Some u...**Documentation - upgrading Kea servers with a common DB backend**
Kea implementations where servers do not share common databases Kea may be upgraded individually.
In this way the down time of dhcp services may be limited.
Some users employ a common database backend for leases and/or configuration data.
As Kea software upgrades normally increment database schema versions, individual upgrades may have unfortunate side effects.
We would like advice regarding this type of upgrade added to:
4.3.2.2 Upgrading a MySQL Database From an Earlier Version of Kea
4.3.3.3 Upgrading a PostgreSQL Database From an Earlier Version of Keanext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2972Empty hardware addresses not handled by PostgreSQL lease manager.2023-08-31T13:54:12ZFrancis DupontEmpty hardware addresses not handled by PostgreSQL lease manager.The PostgreSQL lease manager creates a type 1 (ETHER) hardware address on empty value for v4 leases instead to leave a null pointer (aka "none").
Minor bug so leaving it to next triage.The PostgreSQL lease manager creates a type 1 (ETHER) hardware address on empty value for v4 leases instead to leave a null pointer (aka "none").
Minor bug so leaving it to next triage.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2345Kea 2.0.0 Fails to Allocate Leases2022-11-02T15:10:41ZALOK KUMAR SINGHKea 2.0.0 Fails to Allocate LeasesWe are using Kea 2.0.0 version with backend database postgresql and observer an issue where lease not getting allocated/extended and producing below error message.
Note: Kea and Postgresql database is installed on same VM and has timez...We are using Kea 2.0.0 version with backend database postgresql and observer an issue where lease not getting allocated/extended and producing below error message.
Note: Kea and Postgresql database is installed on same VM and has timezone EST set, also database timezone is set to EST but still this issue is happening, though this was running perfect from last 3 months after an upgrade from 1.5.0P1 to 2.0.0
```
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.dhcp4/1541.140278882691264] DHCP4_CLASS_ASSIGNED [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: client packet has been assigned to the following class(es): UNKNOWN
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.dhcp4/1541.140278882691264] DHCP4_CLASS_ASSIGNED [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: client packet has been assigned to the following class(es): ALL, HA_codcmdndh001, VENDOR_CLASS_MSFT 5.0, UNKNOWN
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.ddns/1541.140278882691264] DHCP4_CLIENT_FQDN_PROCESS [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: processing Client FQDN option
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.ddns/1541.140278882691264] DHCP4_CLIENT_FQDN_DATA [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: Client sent FQDN option: type=81 (CLIENT_FQDN), flags: (N=0, E=0, O=0, S=0), domain-name='compy' (partial)
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.ddns/1541.140278882691264] DHCP4_RESPONSE_FQDN_DATA [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: including FQDN option in the server's response: type=81 (CLIENT_FQDN), flags: (N=1, E=0, O=0, S=0), domain-name='compy.' (full)
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.dhcpsrv/1541.140278882691264] DHCPSRV_PGSQL_GET_CLIENTID obtaining IPv4 leases for client ID 01:9c:ad:97:16:83:2f
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 2 and IPv4 address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.52.67.126, found 0 host(s)
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 2 and address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.dhcpsrv/1541.140278882691264] DHCPSRV_PGSQL_GET_ADDR4 obtaining IPv4 lease for address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.alloc-engine/1541.140278882691264] ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: extending lifetime of the lease for address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.dhcpsrv/1541.140278882691264] DHCPSRV_PGSQL_UPDATE_ADDR4 updating IPv4 lease for address 10.52.67.126
2022-03-07 01:48:13.031 ERROR [kea-dhcp4.alloc-engine/1541.140278882691264] ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: error during attempt to allocate an IPv4 address: unable to update lease for address 10.52.67.126 as it does not exist
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.bad-packets/1541.140278882691264] DHCP4_PACKET_NAK_0004 [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: failed to grant a lease, client sent ciaddr 0.0.0.0, requested-ip-address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.callouts/1541.140278882691264] HOOKS_CALLOUTS_BEGIN begin all callouts for hook leases4_committed
```
[6mar.pcap](/uploads/819df2d10bd7335b39dae233f837379e/6mar.pcap)[kea-dhcp4.log.10](/uploads/64ac95d818035cf59d7ba2f75604e770/kea-dhcp4.log.10)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2263Kea database cluster issue2023-04-14T14:17:49Zkpramodk46Kea database cluster issuewhen we are using in postgres database cluster (Syn and async) for kea dhcp server then it will showing the error message and also remove the ip address when lease has been expired but when we are using single node database(without clust...when we are using in postgres database cluster (Syn and async) for kea dhcp server then it will showing the error message and also remove the ip address when lease has been expired but when we are using single node database(without cluster) it is perfectly fine. My database service and dhcp service are up.
What is issue? please help....
![Kea_error_issue](/uploads/f7db45c5b9c1b8c3b481d83d711206dc/Kea_error_issue.JPG)
```
Jan 06 17:22:04 stag-kea-dhcp.nic.in kea-dhcp4[3999]: INFO DHCP4_LEASE_ADVERT [hwtype=1 c0:3f:d5:46:32:48], cid=[01:c0:3f:d5:46:32:48>
Jan 06 17:22:04 stag-kea-dhcp.nic.in kea-dhcp4[3999]: ERROR ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 c0:3f:d5:46:32:48], cid=[01:c0:3f:d5>
Jan 06 17:22:04 stag-kea-dhcp.nic.in kea-dhcp4[3999]: INFO DHCP4_LEASE_ADVERT [hwtype=1 c0:3f:d5:46:32:48], cid=[01:c0:3f:d5:46:32:48>
Jan 06 17:22:04 stag-kea-dhcp.nic.in kea-dhcp4[3999]: ERROR ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 c0:3f:d5:46:32:48], cid=[01:c0:3f:d5>
Jan 06 17:22:04 stag-kea-dhcp.nic.in kea-dhcp4[3999]: INFO DHCP4_LEASE_ADVERT [hwtype=1 c0:3f:d5:46:32:48], cid=[01:c0:3f:d5:46:32:48>
Jan 06 17:22:04 stag-kea-dhcp.nic.in kea-dhcp4[3999]: ERROR ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 c0:3f:d5:46:32:48], cid=[01:c0:3f:d5>
Jan 06 17:22:04 stag-kea-dhcp.nic.in kea-dhcp4[3999]: INFO DHCP4_LEASE_ADVERT [hwtype=1 c0:3f:d5:46:32:48], cid=[01:c0:3f:d5:46:32:48>
Jan 06 17:22:04 stag-kea-dhcp.nic.in kea-dhcp4[3999]: ERROR ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 c0:3f:d5:46:32:48], cid=[01:c0:3f:d5>
Jan 06 17:22:04 stag-kea-dhcp.nic.in kea-dhcp4[3999]: INFO DHCP4_LEASE_ADVERT [hwtype=1 c0:3f:d5:46:32:48], cid=[01:c0:3f:d5:46:32:48>
Jan 06 17:22:04 stag-kea-dhcp.nic.in kea-dhcp4[3999]: ERROR ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 c0:3f:d5:46:32:48], cid=[01:c0:3f:d5>```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2230Optionally put the database password in a file2023-08-21T14:05:56ZFrancis DupontOptionally put the database password in a fileExtension of #2006 to database configuration. With #34 aka database communication over SSL/TLS this will greatly improve security.Extension of #2006 to database configuration. With #34 aka database communication over SSL/TLS this will greatly improve security.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2037Improve expired leases reclamation query for PostgreSQL2022-11-02T15:10:41ZThomas MarkwalderImprove expired leases reclamation query for PostgreSQLExtended performance testing revealed cyclic slow downs that correspond to expired lease reclamation. The MySQL query was doing full table scans, this was mitigated under #2030. We need to examine PostgreSQL performance and see if it ca...Extended performance testing revealed cyclic slow downs that correspond to expired lease reclamation. The MySQL query was doing full table scans, this was mitigated under #2030. We need to examine PostgreSQL performance and see if it can be improved.backlogMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1969Packet drops seen for 20 sec on every 8th day when perf_dhcp tests are run ag...2022-11-02T15:10:41ZvarsrajaPacket drops seen for 20 sec on every 8th day when perf_dhcp tests are run against Kea DHCP service continuouslyHi All,
We are running performance tests for kea dhcp using the perf-dhcp provided by kea .
- Setup: Dockerized Kea1.6.2 running in well provisioned hardware.
- Runs details: Running perf-dhcp to generate approx 100 requests/ sec , val...Hi All,
We are running performance tests for kea dhcp using the perf-dhcp provided by kea .
- Setup: Dockerized Kea1.6.2 running in well provisioned hardware.
- Runs details: Running perf-dhcp to generate approx 100 requests/ sec , validating all 4 packet handling DHCP discover request etc.
perfdhcp -p 600 -r 100 10.0.0.4 -t 10 this is executed in a loop
- Issue : We observe a 20sec packet drops on requests on every 8th day exactly. The in between days there are no packet losses. There are no restarts of kea-dhcp service. After the packet loss duration, things go back to normal.
- Request: Is there any limits we might be hitting every 8th day of the run? Are there any parameters we should check?
It would be very helpful, if we can determine what causes this packet loss.
Attaching our config for kea-dhcp4.conf and kea-dhcp-ddns.conf[kea-dhcp4.conf](/uploads/a25452141ff09d39ea5457288135c3c9/kea-dhcp4.conf)[kea-dhcp-ddns.conf](/uploads/9651904743e169891229666ee707effb/kea-dhcp-ddns.conf)![dhcp-graph-packet-loss](/uploads/2442b96fb947cf0ccf34e931c326b476/dhcp-graph-packet-loss.png)
![dhcp-test-run](/uploads/2f64b24ab37c54ae447df067455da3c2/dhcp-test-run.png)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1968postgres back-end does not use mktime to convert to local timezone2022-11-02T15:10:40ZRazvan Becheriupostgres back-end does not use mktime to convert to local timezonepostgres reads data using extract epoch and boost::lexical_cast (UTC) but writes data using localtime_r (timezone time and date).
this causes update queries to fail if kea timezone is different than postgres back-end timezone.
fix shou...postgres reads data using extract epoch and boost::lexical_cast (UTC) but writes data using localtime_r (timezone time and date).
this causes update queries to fail if kea timezone is different than postgres back-end timezone.
fix should be (pseudo code):
‘’’
mktime(gmtime_r(boost::lexical_cast(extrach epoch)))
‘’’backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1643Missing foreign key for lease6.hwaddr_source2022-11-02T15:10:19ZSander SteffannMissing foreign key for lease6.hwaddr_source**Describe the bug**
When inspecting the database structure I noticed (using PostgreSQL) that `lease6.hwaddr_source` is not a foreign key to `lease_hwaddr_source.hwaddr_source`. This seems inconsistent as both `lease6.state` and `lease6...**Describe the bug**
When inspecting the database structure I noticed (using PostgreSQL) that `lease6.hwaddr_source` is not a foreign key to `lease_hwaddr_source.hwaddr_source`. This seems inconsistent as both `lease6.state` and `lease6.lease_type` are foreign keys.
**To Reproduce**
Steps to reproduce the behavior:
1. Run `kea-admin db-init pgsql`
2. Connect to the kea database using `psql`
3. Check the database schema with `\d lease6`
**Expected behavior**
I would expect `lease6.hwaddr_source` to be a foreign key as it references values in another table.
**Environment:**
- Kea version: isc-kea-admin, deb package 1.9.3-isc001302020121418142
- OS: Debian GNU/Linux 10 (buster)
**Additional Information**
None
**Contacting you**
sander@steffann.nl or +31-6-22660412backloghttps://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/349Restricting timestamps in Kea backends to max supported values2022-11-02T15:08:42ZMarcin SiodelskiRestricting timestamps in Kea backends to max supported valuesThe following chapter of the Kea User's Guide `Limitations Related to the use of SQL Databases` claims that we restricted timestamps to 32 bit value past the epoch. I don't see us restricting this anywhere. Maybe we should revise which d...The following chapter of the Kea User's Guide `Limitations Related to the use of SQL Databases` claims that we restricted timestamps to 32 bit value past the epoch. I don't see us restricting this anywhere. Maybe we should revise which databases have which limitation and explicitly report an error upon an attempt to add higher timestamps.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/269client_encoding in PostgreSQL connection2022-11-02T15:08:44ZGhost Userclient_encoding in PostgreSQL connection---
name: client_encoding in PostgreSQL connection
about: Make connection's client_encoding configurable
---
**Related problem**
Sometimes it is impossible to execute lease{4,6}_{update,insert} SQLs in configuration with PostgreSQL dat...---
name: client_encoding in PostgreSQL connection
about: Make connection's client_encoding configurable
---
**Related problem**
Sometimes it is impossible to execute lease{4,6}_{update,insert} SQLs in configuration with PostgreSQL database created with default UTF8 encoding and default server's encoding set to UTF8. This is because some DHCP clients are not fully compatible with RFC1035 and are using 8-bit ASCII codes in hostname options. This, in case, results in errors like '2018-11-12 23:36:44.762 ERROR [kea-dhcp4.alloc-engine/30224] ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 a0:f3:c1:9d:33:d5], cid=[01:a0:f3:c1:9d:33:d5], tid=0x55527316: error during attempt to allocate an IPv4 address: Statement exec failed: for: update_lease4, status: 7sqlstate:[ 22021], reason: ERROR: invalid byte sequence for encoding "UTF8": 0xc0 0x90'
**Solution**
One possible solution is to change "client_encoding" connection parameter to "latin1" value. This eliminates problem of PostgreSQL's parsing such problematic string as UTF8 string and makes it possible to store hostname value "as is".
To make this connection parameter configurable, I've added configuration parameter "client-encoding" visible in LEASE_DATABASE, HOSTS_DATABASE and CONFIG_DATABASE scopes.
I've attached the patch against today's master branch of repo.
I can also make a pull request, if you need it
Also, I can backport this patch to 1.4.0 and 1.5.0 version, because it fixes some possible problems
[client_encoding_master.patch](/uploads/db18cf7ffa25ca65bbfaa1a825cf73ca/client_encoding_master.patch)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.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2872Enable MySQL, PgSQL in CodeQL2023-05-25T13:47:57ZTomek MrugalskiEnable MySQL, PgSQL in CodeQL#2760 enabled github's CodeQL checks. However, there were difficulties for MySQL, and Postgres (see [this thread](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1952#note_362168) and the links in it). It seems hammer had some d...#2760 enabled github's CodeQL checks. However, there were difficulties for MySQL, and Postgres (see [this thread](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1952#note_362168) and the links in it). It seems hammer had some difficulties installing dependencies and then accessing the database.
Note: CodeQL is only available on github. This is the first pipeline we have for our mirror on github. This ticket may cover other generic changes.
The goal of this ticket is to figure out why exactly hammer had problems, fix them and enable both MySQL and Postgres.
We have a separate [repo](https://github.com/isc-projects/kea-experiments) for experiments with github. This may come in handy.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2307use reference when calling getTags2022-05-30T11:19:30ZRazvan Becheriuuse reference when calling getTagsthe following code should be optimised:
```
auto tags = server_selector.getTags();
for (auto tag : tags) {
```
to
```
const auto& tags = server_selector.getTags();
for (const auto& tag : tags) {
```
the ge...the following code should be optimised:
```
auto tags = server_selector.getTags();
for (auto tag : tags) {
```
to
```
const auto& tags = server_selector.getTags();
for (const auto& tag : tags) {
```
the getTags returns a copy of a set:
```
std::set<data::ServerTag> getTags() const {
return (tags_);
}
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2306PsqlBindArray::addTempString should be used for temp strings only2022-05-30T11:19:24ZRazvan BecheriuPsqlBindArray::addTempString should be used for temp strings onlythe use of PsqlBindArray::addTempString should be avoided if possible because it uses heap for a new string.
if the strings have long scope/lifetime, PsqlBindArray::add should be used insteadthe use of PsqlBindArray::addTempString should be avoided if possible because it uses heap for a new string.
if the strings have long scope/lifetime, PsqlBindArray::add should be used insteadoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1045Implement wipe commands for PgSQL and MySQL2020-04-29T10:35:15ZTomek MrugalskiImplement wipe commands for PgSQL and MySQL@fdupont reported that wipe commands for MySQL and PgSQL are not implemented. This is an unfortunate omission.
We need to implement them.
One thing to do is to look at older branches. Perhaps there's some code there. I vaguely recall t...@fdupont reported that wipe commands for MySQL and PgSQL are not implemented. This is an unfortunate omission.
We need to implement them.
One thing to do is to look at older branches. Perhaps there's some code there. I vaguely recall they were being discussed with some code written, but I may be misremembering.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/792quality of life improvement: kea-admin db-version fails on empty db2022-03-31T08:12:51ZTomek Mrugalskiquality of life improvement: kea-admin db-version fails on empty dbkea-admin db-version prints the following error:
```
# kea-admin db-version mysql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1146 (42S02) at line 1: Table 'keatest.schema_version' doesn't exis...kea-admin db-version prints the following error:
```
# kea-admin db-version mysql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1146 (42S02) at line 1: Table 'keatest.schema_version' doesn't exist
```
when run on an empty DB (without any schema).
Instead, it should catch the fact that schema_version does not exist and should point user to kea-admin db-init command.
This is a quality of life improvement, so it's not terribly important.outstanding