Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2021-07-29T14:50:36Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1919ZTP with KEA for Huawei switches2021-07-29T14:50:36ZBranka AndrijasevicZTP with KEA for Huawei switchesHi ISC Support,
In the context of using KEA DHCP for ZTP of Huawei Switches, we’re right now facing an issue within the implementation of RFC Compliance within KEA DHCP.
Based on the documentation of Huawei (see https://support.hu...Hi ISC Support,
In the context of using KEA DHCP for ZTP of Huawei Switches, we’re right now facing an issue within the implementation of RFC Compliance within KEA DHCP.
Based on the documentation of Huawei (see https://support.huawei.com/enterprise/en/doc/EDOC0100533703?section=j004) the Switch Firmware is relying on the overlapping Options 141 + 146 (see https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#id2) which are conflicting in terms of DHCP Option Type.
We would therefore kindly ask ISC to review this issue, as it’s entirely blocking the introduction of ZTP / Autoconfiguration of Huawei Switches within our installation base.
In case no solution exists out of the box, we would further ask ISC to consider a compatibility option for allowing the override of standard RFC-ed options, see e.g. https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#kea-dhcpv4-compatibility-configuration-parameters
Kind Regardsoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1693git tag vs configure.ac version2021-08-03T13:15:28ZGene Cgit tag vs configure.ac version
Hi
Would you consider keeping the git tag in master in sync with the version in configure.ac?
As of now git tag is 1.9.4 while configure uses 1.9.5
```
$ git tag -l Kea-'[0-9]*' --sort=creatordate|tail -1
Kea-1.9.4
```
while :
```
$...
Hi
Would you consider keeping the git tag in master in sync with the version in configure.ac?
As of now git tag is 1.9.4 while configure uses 1.9.5
```
$ git tag -l Kea-'[0-9]*' --sort=creatordate|tail -1
Kea-1.9.4
```
while :
```
$ grep AC_INIT configure.ac
AC_INIT(kea,1.9.5-git, kea-dev@lists.isc.org)
```kea1.9.10https://gitlab.isc.org/isc-projects/kea/-/issues/725Consistency of Element constness in Element containers2021-08-20T14:15:47ZAndrei Pavelandrei@isc.orgConsistency of Element constness in Element containers```
class ListElement : public Element {
std::vector<ElementPtr> l;
[...]
}
```
```
class MapElement : public Element {
std::map<std::string, ConstElementPtr> m;
[...]
}
```
Making these containers have the same const...```
class ListElement : public Element {
std::vector<ElementPtr> l;
[...]
}
```
```
class MapElement : public Element {
std::map<std::string, ConstElementPtr> m;
[...]
}
```
Making these containers have the same constness for the underlying type would enable less friction in:
1. Generic helper functions acting on both
2. Generic high-level use of both
04fa0d3f0b83d544044475cd51de100faf17a410 changed ListElement to hold ElementPtr instead of ConstElementPtr.
Would you consider it?outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1995How should structurally-nested MySQL transactions be handled?2021-09-03T04:15:16ZAndrei Pavelandrei@isc.orgHow should structurally-nested MySQL transactions be handled?The [MySQL docs](https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html) state:
> Transactions cannot be nested. This is a consequence of the implicit commit performed for any current transaction when you issue a START TRANSACTION...The [MySQL docs](https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html) state:
> Transactions cannot be nested. This is a consequence of the implicit commit performed for any current transaction when you issue a START TRANSACTION statement or one of its synonyms.
Since 1.9.10, Kea no longer relies on this default behavior. Commits 4ba460d0f9f1b4f532da8e13d2aa4109124229ec and 83a5989497ee8831ca55b4c0987ee2fd3a369c56 have made it so that the statements belonging to the inner transactions are re-assigned to the outermost transaction. This is arguably better than the MySQL default, because the statements of the inner transaction keep their atomicity (and probably other properties that transaction ensure), instead of it being split into smaller atomic portions, like in the default scenario.
But... A side effect is that the result of the inner transaction is ignored. I don't see this being a problem in case the inner transaction would have committed. But it might be a problem if the inner transaction had decided to rollback. Post-1.9.10, if the outermost transaction decides to commit, the otherwise rolled back statements will now also be committed.
Better(?) alternatives:
* prioritize rollbacks so that a rolled back inner transaction results in a rolled back outer transaction
* turn inner transactions (decided by an if branch in code) into savepoints:
* turn "START TRANSACTION" into "SAVEPOINT identifier"
* turn "ROLLBACK" into "ROLLBACK [WORK] TO [SAVEPOINT] identifier"
* turn "COMMIT" into "RELEASE SAVEPOINT identifier"outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2076Move DB-related code out of libprocess2021-09-16T15:12:53ZAndrei Pavelandrei@isc.orgMove DB-related code out of libprocessThis is just a parent issue for !110 which had closed issue #156 as parent.This is just a parent issue for !110 which had closed issue #156 as parent.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2093Follow-up from "Draft: Resolve "add core parking lot limit as congestion reco...2021-09-16T15:34:36ZThomas MarkwalderFollow-up from "Draft: Resolve "add core parking lot limit as congestion recovery for the HA / HTTP service""The following discussion from !1402 should be addressed:
- [ ] @fdupont started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1402#note_235475): (+2 comments)
> The described behavior is not the best: ins...The following discussion from !1402 should be addressed:
- [ ] @fdupont started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1402#note_235475): (+2 comments)
> The described behavior is not the best: instead of dropping the query IMHO it is better to drop the response. Of course the response was built so we drop already done work but if the query was retransmitted the response is obsolete so useless. This argument is stronger with slow servers and big parking lots but this case is the one the limit is interesting...outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2074NAK sent to it's own offer IP2021-09-17T12:04:58ZALOK KUMAR SINGHNAK sent to it's own offer IPUpgraded Kea 1.5 to 1.8.2 version, post upgrade I have observed reserved clients doesn't receive IP address. When did packet capture could see DHCP server sends NAK packet to it's own reserved IP address offered.
Please find the packet...Upgraded Kea 1.5 to 1.8.2 version, post upgrade I have observed reserved clients doesn't receive IP address. When did packet capture could see DHCP server sends NAK packet to it's own reserved IP address offered.
Please find the packet captured attached and let me know if it's a bug in kea1.8.2?
Filter MAC- 10:65:30:FA:76:AC
[hsclab.pcap](/uploads/922e5fae16d79108612088e8348c90d8/hsclab.pcap)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1573fix warnings when compiling with -pedantic or -Wpedantic2021-09-28T09:40:55ZAndrei Pavelandrei@isc.orgfix warnings when compiling with -pedantic or -Wpedanticonly if the problem that the compiler reports is real and if an agreeable fix can be done, of course
shouldn't be too big of an effort
i think we already are warning-free for `-Wall` and `-Wextra`
```
export CXXFLAGS='-pedantic'
./con...only if the problem that the compiler reports is real and if an agreeable fix can be done, of course
shouldn't be too big of an effort
i think we already are warning-free for `-Wall` and `-Wextra`
```
export CXXFLAGS='-pedantic'
./configure
make
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1465Get rid of --with-gtest2021-10-19T07:33:30ZFrancis DupontGet rid of --with-gtestIt is universally known that to provide a system wide gtest is not the best idea, for instance on macOS homebrew says:
```
% brew search gtest
Installing gtest system-wide is not recommended; it should be vendored
in your projects that u...It is universally known that to provide a system wide gtest is not the best idea, for instance on macOS homebrew says:
```
% brew search gtest
Installing gtest system-wide is not recommended; it should be vendored
in your projects that use it.
```
We have both --with-gtest and --with-gtest-source so one should be removed: clearly --with-gtest should be removed and --with-gtest-source used by all persons wanting unit tests.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1444LeaseX-update and leaseX-del cmds must be propaged to ha members2021-10-19T07:34:04Zmirackle-spbLeaseX-update and leaseX-del cmds must be propaged to ha members---
name: Feature request
about: leaseX-update and leaseX-del cmds must be propaged to ha members
---
**Some initial questions**
Sometimes i need to update or delete leases. But i need to send update to all ha members.
Sending request ...---
name: Feature request
about: leaseX-update and leaseX-del cmds must be propaged to ha members
---
**Some initial questions**
Sometimes i need to update or delete leases. But i need to send update to all ha members.
Sending request to primary is not enough. I need to send same request to stand-by member.
**Describe the solution you'd like**
Send update and del cmds to all ha members after completion on one node to maintain sync.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1125rebuild statistic-get-all response2021-10-19T07:37:07ZWlodzimierz Wencelrebuild statistic-get-all responseAt this point this is what kea is sending back:
```
{
"command": "statistic-get-all",
"arguments": {
"declined-addresses": [ [ 0, "2019-07-30 10:04:28.386733" ] ],
"reclaimed-declined-addresses": [ [ 0, "2019-07-3...At this point this is what kea is sending back:
```
{
"command": "statistic-get-all",
"arguments": {
"declined-addresses": [ [ 0, "2019-07-30 10:04:28.386733" ] ],
"reclaimed-declined-addresses": [ [ 0, "2019-07-30 10:04:28.386735" ] ],
"reclaimed-leases": [ [ 0, "2019-07-30 10:04:28.386736" ] ],
"subnet[1].assigned-addresses": [ [ 0, "2019-07-30 10:04:28.386740" ] ],
"subnet[1].declined-addresses": [ [ 0, "2019-07-30 10:04:28.386743" ] ],
"subnet[1].reclaimed-declined-addresses": [ [ 0, "2019-07-30 10:04:28.386745" ] ],
"subnet[1].reclaimed-leases": [ [ 0, "2019-07-30 10:04:28.386747" ] ],
"subnet[1].total-addresses": [ [ 200, "2019-07-30 10:04:28.386719" ] ]
},
"result": 0
}
```
I want to focus on a prat with subnets, which is really hard to parse. Biggest issue is that subnet id is in key name, not as value. And this is completely flat.
I am proposing to return statistics like that:
```
{
"command": "statistic-get-all",
"arguments": {
"declined-addresses": [ [ 0, "2019-07-30 10:04:28.386733" ] ],
"reclaimed-declined-addresses": [ [ 0, "2019-07-30 10:04:28.386735" ] ],
"reclaimed-leases": [ [ 0, "2019-07-30 10:04:28.386736" ] ],
"subnets": { [
"subnet-id": 1,
"assigned-addresses": [ [ 0, "2019-07-30 10:04:28.386740" ] ],
"declined-addresses": [ [ 0, "2019-07-30 10:04:28.386743" ] ],
"reclaimed-declined-addresses": [ [ 0, "2019-07-30 10:04:28.386745" ] ],
"reclaimed-leases": [ [ 0, "2019-07-30 10:04:28.386747" ] ],
"total-addresses": [ [ 200, "2019-07-30 10:04:28.386719" ] ]
],
[
"subnet-id": 2,
"assigned-addresses": [ [ 0, "2019-07-30 10:04:28.386740" ] ],
"declined-addresses": [ [ 0, "2019-07-30 10:04:28.386743" ] ],
"reclaimed-declined-addresses": [ [ 0, "2019-07-30 10:04:28.386745" ] ],
"reclaimed-leases": [ [ 0, "2019-07-30 10:04:28.386747" ] ],
"total-addresses": [ [ 200, "2019-07-30 10:04:28.386719" ] ]
]
}
},
"result": 0
}
```
I came up on this issue while working recently with performance testing of a setup with ~500 subnets.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/656Need more checks on global parameters.2021-10-20T09:44:17ZFrancis DupontNeed more checks on global parameters.Reference https://gitlab.isc.org/isc-projects/kea/issues/576#note_61000 second problem: invalid values for global parameters should be rejected even they are not used:
- for individual parameters, e.g. next-server sets to something not ...Reference https://gitlab.isc.org/isc-projects/kea/issues/576#note_61000 second problem: invalid values for global parameters should be rejected even they are not used:
- for individual parameters, e.g. next-server sets to something not parse-able as an IPv4 address (nor empty)
- between parameters, e.g. 0 <= t1_percent <= 1 and t1_percent < t2_percent
The ideas are:
- avoid cases where the config backend is used to create a configuration which can't be saved and reloaded (get then set or write then reload fails)
- avoid cases where a global parameter with an invalid value is added/accepted and the invalid will raise an error a long time ago when an update will first use it (e.g. configuration built incrementally starting by global parameters, IMHO could be a popular way to proceed).
To summary the current check on global parameter value type is fine but not enough. Related to #576, #535 and #513outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/811autotools variables in installed documentation.2021-10-20T09:44:18ZFrancis Dupontautotools variables in installed documentation.A grep for `@prefix@` or `@...dir@` in installed Kea shows that `share/doc/kea/html/_sources/arm/keactrl.rst.txt` and `share/doc/kea/html/arm/keactrl.html` contain unexpanded autotools variables in config file code blocks.
Some possible...A grep for `@prefix@` or `@...dir@` in installed Kea shows that `share/doc/kea/html/_sources/arm/keactrl.rst.txt` and `share/doc/kea/html/arm/keactrl.html` contain unexpanded autotools variables in config file code blocks.
Some possible solutions:
- do nothing as these code blocks are just a copy of the original (before substitution) config files
- edit the code blocks to expand manually these variables to something more human friendly
- expand the original source file before processing
- include the real config files (of course after expansion): if it is feasible it is the best (easier maintenance, etc).outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/835on FreeBSD Kea should prefer clang instead of gcc2021-10-20T09:44:18ZMichal Nowikowskion FreeBSD Kea should prefer clang instead of gccas it fails on linking with log4cplus.
It could be done in configure.ac this way:
```
if uname="FreeBSD"
# override configure preference for gcc
AC_PROG_CC(clang llvm-gcc gcc)
AC_PROG_CXX(clang++ llvm-g++ g++)
else
AC_PROG_CC
...as it fails on linking with log4cplus.
It could be done in configure.ac this way:
```
if uname="FreeBSD"
# override configure preference for gcc
AC_PROG_CC(clang llvm-gcc gcc)
AC_PROG_CXX(clang++ llvm-g++ g++)
else
AC_PROG_CC
AC_PROG_CXX
fi
```
this is based on: https://lists.freebsd.org/pipermail/freebsd-toolchain/2013-September/001038.htmloutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/808server-tag is itself a global parameter2021-10-20T09:44:18ZFrancis Dupontserver-tag is itself a global parameterserver-tag is itself a global parameter so someone could have the bad idea to manage it using the config backend.
The sanity check fro global parameters in CB must check the global parameter is not server-tag. Note this applies for all ...server-tag is itself a global parameter so someone could have the bad idea to manage it using the config backend.
The sanity check fro global parameters in CB must check the global parameter is not server-tag. Note this applies for all global parameter commands even get will not lead to a disaster...outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/598forbid using empty string as value of shared-network-name parameter in remote...2021-10-20T09:44:18ZWlodzimierz Wencelforbid using empty string as value of shared-network-name parameter in remote-subnet4-set commandright now values that are allowed are:
- non empty string
- empty string
- null
And two of them have the same result, I propose forbidding `"shared-network-name": ""` to avoid misusing this parameter.right now values that are allowed are:
- non empty string
- empty string
- null
And two of them have the same result, I propose forbidding `"shared-network-name": ""` to avoid misusing this parameter.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/723Missing CB entry for deleting all global options2021-10-20T09:47:17ZFrancis DupontMissing CB entry for deleting all global optionsObviously either we have to add a deleteAllOptions4 or remove `remote-option4-global-del-all` from the design. Note as the CB command is starred this should be postponed...Obviously either we have to add a deleteAllOptions4 or remove `remote-option4-global-del-all` from the design. Note as the CB command is starred this should be postponed...outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1178Spurious semi-colon after namespace closing brace.2021-10-20T09:47:46ZFrancis DupontSpurious semi-colon after namespace closing brace.In this code:
```
namespace foo {
...
};
```
the semi-colon is useless. It seems a version of clang complains so:
- update the coding guide-line
- chase and fix them
- at the occasion (*) fix them in a file where the code is changed
...In this code:
```
namespace foo {
...
};
```
the semi-colon is useless. It seems a version of clang complains so:
- update the coding guide-line
- chase and fix them
- at the occasion (*) fix them in a file where the code is changed
(*) it is clearly unrelated so do it only for **small** MRs so **not** for syntax change MRsoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1846sanity checks: v6 unit tests tweaks on macOS2021-10-20T10:16:05ZTomek Mrugalskisanity checks: v6 unit tests tweaks on macOSAs reported by @fdupont [here](https://gitlab.isc.org/isc-projects/kea/-/issues/1827#note_209771):
macOS 11.2.3 Xcode 12.4 I got twice on three attempts this error:
```
[ RUN ] RunScriptTest.lease6Recover
../../../../../../../src/h...As reported by @fdupont [here](https://gitlab.isc.org/isc-projects/kea/-/issues/1827#note_209771):
macOS 11.2.3 Xcode 12.4 I got twice on three attempts this error:
```
[ RUN ] RunScriptTest.lease6Recover
../../../../../../../src/hooks/dhcp/run_script/tests/run_script_unittests.cc:731: Failure
Expected: (time(__null)) < (now + 3), actual: 1619475859 vs 1619475859
timeout
[ FAILED ] RunScriptTest.lease6Recover (2355 ms)
```
and
```
[ RUN ] RunScriptTest.lease6Decline
../../../../../../../src/hooks/dhcp/run_script/tests/run_script_unittests.cc:731: Failure
Expected: (time(__null)) < (now + 3), actual: 1619520686 vs 1619520686
timeout
[ FAILED ] RunScriptTest.lease6Decline (2127 ms)
```
Two comments:
- NULL does not exist in C++: please change time(NULL) by time(0)
- the checkScriptResult code obviously requires some rewritesoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1260avoid more race conditions2021-10-20T10:18:11ZRazvan Becheriuavoid more race conditionsit seems that addLease, updateLease and deleteLease are called in several other places. we should lock the resource there as well:
```
Dhcpv4Srv::processRelease
Dhcpv4Srv::declineLease
Dhcpv6Srv::releaseIA_NA
Dhcpv6Srv::releaseIA_PD
Dh...it seems that addLease, updateLease and deleteLease are called in several other places. we should lock the resource there as well:
```
Dhcpv4Srv::processRelease
Dhcpv4Srv::declineLease
Dhcpv6Srv::releaseIA_NA
Dhcpv6Srv::releaseIA_PD
Dhcpv6Srv::declineLease
Dhcpv6Srv::generateFqdn
LeaseCmdsImpl::lease6BulkApplyHandler - there is a leaseDelete which can cause other races.
LeaseCmdsImpl::lease4DelHandler - will cause race
LeaseCmdsImpl::lease6DelHandler - will cause race
AllocEngine::allocateReservedLeases6
from AllocEngine::allocateLeases6
from Dhcpv6Srv::assignIA_NA
from Dhcpv6Srv::assignIA_PD
from AllocEngine::renewLeases6
from Dhcpv6Srv::extendIA_NA
from Dhcpv6Srv::extendIA_PD
AllocEngine::allocateGlobalReservedLeases6
from AllocEngine::allocateReservedLeases6
AllocEngine::removeNonmatchingReservedLeases6
from AllocEngine::allocateLeases6
from Dhcpv6Srv::assignIA_NA
from Dhcpv6Srv::assignIA_PD
from AllocEngine::renewLeases6
from Dhcpv6Srv::extendIA_NA
from Dhcpv6Srv::extendIA_PD
AllocEngine::removeNonmatchingReservedNoHostLeases6
from AllocEngine::removeNonmatchingReservedLeases6
from AllocEngine::allocateLeases6
from Dhcpv6Srv::assignIA_NA
from Dhcpv6Srv::assignIA_PD
from AllocEngine::renewLeases6
from Dhcpv6Srv::extendIA_NA
from Dhcpv6Srv::extendIA_PD
AllocEngine::removeNonreservedLeases6
from AllocEngine::allocateLeases6
from Dhcpv6Srv::assignIA_NA
from Dhcpv6Srv::assignIA_PD
from AllocEngine::renewLeases6
from Dhcpv6Srv::extendIA_NA
from Dhcpv6Srv::extendIA_PD
AllocEngine::reuseExpiredLease
from AllocEngine::allocateUnreservedLeases6
from AllocEngine::allocateLeases6
from Dhcpv6Srv::assignIA_NA
from Dhcpv6Srv::assignIA_PD
from AllocEngine::renewLeases6
from Dhcpv6Srv::extendIA_NA
from Dhcpv6Srv::extendIA_PD
AllocEngine::createLease6
from AllocEngine::allocateUnreservedLeases6
from AllocEngine::allocateLeases6
from Dhcpv6Srv::assignIA_NA
from Dhcpv6Srv::assignIA_PD
from AllocEngine::renewLeases6
from Dhcpv6Srv::extendIA_NA
from Dhcpv6Srv::extendIA_PD
from AllocEngine::allocateReservedLeases6
from AllocEngine::allocateLeases6
from Dhcpv6Srv::assignIA_NA
from Dhcpv6Srv::assignIA_PD
from AllocEngine::renewLeases6
from Dhcpv6Srv::extendIA_NA
from Dhcpv6Srv::extendIA_PD
from AllocEngine::allocateGlobalReservedLeases6
from AllocEngine::allocateLeases6
from Dhcpv6Srv::assignIA_NA
from Dhcpv6Srv::assignIA_PD
from AllocEngine::renewLeases6
from Dhcpv6Srv::extendIA_NA
from Dhcpv6Srv::extendIA_PD
AllocEngine::extendLease6
from AllocEngine::renewLeases6
from Dhcpv6Srv::extendIA_NA
from Dhcpv6Srv::extendIA_PD
AllocEngine::updateLeaseData
from AllocEngine::allocateLeases6
from Dhcpv6Srv::assignIA_NA
from Dhcpv6Srv::assignIA_PD
AllocEngine::deleteExpiredReclaimedLeases6 - will cause race
AllocEngine::deleteExpiredReclaimedLeases4 - will cause race
AllocEngine::reclaimLeaseInDatabase
from AllocEngine::reclaimExpiredLease Lease4Ptr
from AllocEngine::reclaimExpiredLease Lease6Ptr
AllocEngine::reclaimExpiredLease Lease4Ptr
from AllocEngine::reclaimExpiredLeases4 - safe
from AllocEngine::renewLease4
from AllocEngine::reuseExpiredLease4
AllocEngine::reclaimExpiredLease Lease6Ptr
from AllocEngine::reuseExpiredLease
from AllocEngine::extendLease6
from AllocEngine::reclaimExpiredLeases6 - safe
AllocEngine::createLease4
from AllocEngine::allocateOrReuseLease4
from AllocEngine::discoverLease4
from AllocEngine::requestLease4
AllocEngine::requestLease4
from AllocEngine::allocateLease4
from Dhcpv4Srv::assignLease
AllocEngine::renewLease4
from AllocEngine::discoverLease4
from AllocEngine::allocateLease4
from Dhcpv4Srv::assignLease
from AllocEngine::requestLease4
from AllocEngine::allocateLease4
from Dhcpv4Srv::assignLease
AllocEngine::reuseExpiredLease4
from AllocEngine::allocateOrReuseLease4
from AllocEngine::discoverLease4
from AllocEngine::requestLease4
from AllocEngine::allocateUnreservedLease4
from AllocEngine::discoverLease4
from AllocEngine::requestLease4
```outstanding