mirror of
https://gitlab.isc.org/isc-projects/kea
synced 2025-08-30 21:45:37 +00:00
[trac3891] Typo level items
This commit is contained in:
@@ -2727,13 +2727,13 @@ It is merely echoed by the server
|
||||
<para>
|
||||
The server does not decrease assigned-addresses statistics
|
||||
when DHCPDECLINE is received and processed successfully. While
|
||||
technically declined address is not assigned anymore, the primary usage
|
||||
of assigned-addresses statistic is to monitor pool utilization. Most
|
||||
technically a declined address is no longer assigned, the primary usage
|
||||
of the assigned-addresses statistic is to monitor pool utilization. Most
|
||||
people would forget to include declined-addresses in the calculation,
|
||||
and simply do assigned-addresses/total-addresses. This would have a bias
|
||||
towards under-representing pool utilization. As this has a
|
||||
potential for major issues, we decided to decrease assigned
|
||||
addresses not immediately after receiving DHCPDECLINE, but do
|
||||
potential for major issues, we decided not to decrease assigned
|
||||
addresses immediately after receiving DHCPDECLINE, but to do
|
||||
it later when we recover the address back to the available pool.
|
||||
</para>
|
||||
|
||||
|
@@ -194,7 +194,7 @@ detected as a duplicate (i.e. another device in the network is using this addres
|
||||
However, the server does not have a record for this address. This may indicate
|
||||
a client's error or a server's purged database.
|
||||
|
||||
% DHCP4_DECLINE_LEASE_MISMATCH Received DHCPDECLINE for addr %1 from %2, but the data doesn't match: received hwaddr: %3, lease hwaddr: %4, received client-id: %5, lease client-id: %6
|
||||
% DHCP4_DECLINE_LEASE_MISMATCH Received DHCPDECLINE for addr %1 from client %2, but the data doesn't match: received hwaddr: %3, lease hwaddr: %4, received client-id: %5, lease client-id: %6
|
||||
This informational message means that a client attempted to report his address
|
||||
as declined (i.e. used by unknown entity). The server has information about
|
||||
a lease for that address, but the client's hardware address or client identifier
|
||||
|
@@ -1936,8 +1936,8 @@ Dhcpv4Srv::declineLease(const Lease4Ptr& lease, const std::string& descr) {
|
||||
StatsMgr::instance().addValue("declined-addresses", static_cast<int64_t>(1));
|
||||
|
||||
// We do not want to decrease the assigned-addresses at this time. While
|
||||
// technically declined address is not allocated anymore, the primary usage
|
||||
// of assigned-addresses statistic is to monitor pool utilization. Most
|
||||
// technically a declined address is no longer allocated, the primary usage
|
||||
// of the assigned-addresses statistic is to monitor pool utilization. Most
|
||||
// people would forget to include declined-addresses in the calculation,
|
||||
// and simply do assigned-addresses/total-addresses. This would have a bias
|
||||
// towards under-representing pool utilization, if we decreased allocated
|
||||
|
@@ -405,7 +405,7 @@ protected:
|
||||
/// @brief Process incoming DHCPDECLINE messages.
|
||||
///
|
||||
/// This method processes incoming DHCPDECLINE. In particular, it extracts
|
||||
/// Requested IP Address option, check that the address really belongs to
|
||||
/// Requested IP Address option, checks that the address really belongs to
|
||||
/// the client and if it does, calls @ref declineLease.
|
||||
///
|
||||
/// @param decline message received from client
|
||||
|
@@ -197,7 +197,7 @@ DeclineTest::acquireAndDecline(const std::string& hw_address_1,
|
||||
uint64_t after_global = declined_global->getInteger().first;
|
||||
|
||||
ASSERT_TRUE(lease);
|
||||
// We check if the deline process was successful by checking if the
|
||||
// We check if the decline process was successful by checking if the
|
||||
// lease is in the database and what is its state.
|
||||
if (expected_result == SHOULD_PASS) {
|
||||
EXPECT_EQ(Lease::STATE_DECLINED, lease->state_);
|
||||
|
Reference in New Issue
Block a user