]> git.ipfire.org Git - thirdparty/kea.git/commitdiff
[#2908] Addressed comments
authorFrancis Dupont <fdupont@isc.org>
Thu, 3 Aug 2023 14:30:32 +0000 (16:30 +0200)
committerFrancis Dupont <fdupont@isc.org>
Thu, 3 Aug 2023 14:30:32 +0000 (16:30 +0200)
ChangeLog
src/bin/dhcp4/dhcp4_messages.cc
src/bin/dhcp4/dhcp4_messages.mes
src/bin/dhcp6/dhcp6_messages.cc
src/bin/dhcp6/dhcp6_messages.mes

index 8291a7159e512ea0dd69ad36f29d83dbdf3973e2..faff432076457d6f2dcfdf2655dfce064c0bf05d 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,5 @@
 2172.  [func]          fdupont
-       Completed and imporved logs showing what client classes
+       Completed and improved logs showing what client classes
        are assigned to queries during processing.
        (Gitlab #2908)
 
index ebb35e7f6691b676b05a707c1f98642dd9ff9d48..7e461864c9da5ce43cf9b0869087da30d98192a5 100644 (file)
@@ -187,7 +187,7 @@ const char* values[] = {
     "DHCP4_CB_ON_DEMAND_FETCH_UPDATES_FAIL", "error on demand attempt to fetch configuration updates from the configuration backend(s): %1",
     "DHCP4_CB_PERIODIC_FETCH_UPDATES_FAIL", "error on periodic attempt to fetch configuration updates from the configuration backend(s): %1",
     "DHCP4_CB_PERIODIC_FETCH_UPDATES_RETRIES_EXHAUSTED", "maximum number of configuration fetch attempts: 10, has been exhausted without success",
-    "DHCP4_CLASSES_ASSIGNED", "%1: client packet has been assigned to following classes: %2",
+    "DHCP4_CLASSES_ASSIGNED", "%1: client packet has been assigned to the following classes: %2",
     "DHCP4_CLASS_ASSIGNED", "%1: client packet has been assigned to the following class: %2",
     "DHCP4_CLASS_UNCONFIGURED", "%1: client packet belongs to an unconfigured class: %2",
     "DHCP4_CLASS_UNDEFINED", "required class %1 has no definition",
index 3c566477f5098f9cd79e0b41bfe064eceb727e1c..850b27563e9acb1ab36a34460d8665c0e9eae202 100644 (file)
@@ -65,7 +65,7 @@ The server will continue to operate but won't make any further attempts
 to fetch configuration updates. The administrator must fix the configuration
 in the database and reload (or restart) the server.
 
-% DHCP4_CLASSES_ASSIGNED %1: client packet has been assigned to following classes: %2
+% DHCP4_CLASSES_ASSIGNED %1: client packet has been assigned to the following classes: %2
 This debug message informs that incoming packet has been assigned to specified
 classes. This is a normal behavior and indicates successful operation.
 The first argument specifies the client and transaction identification
index f4fd815f97a8293a9622b47a58b2d3c0e9adf80b..6644071fa908353e963ad4f70dace2b4230bf0a8 100644 (file)
@@ -186,7 +186,7 @@ const char* values[] = {
     "DHCP6_CB_ON_DEMAND_FETCH_UPDATES_FAIL", "error on demand attempt to fetch configuration updates from the configuration backend(s): %1",
     "DHCP6_CB_PERIODIC_FETCH_UPDATES_FAIL", "error on periodic attempt to fetch configuration updates from the configuration backend(s): %1",
     "DHCP6_CB_PERIODIC_FETCH_UPDATES_RETRIES_EXHAUSTED", "maximum number of configuration fetch attempts: 10, has been exhausted without success",
-    "DHCP6_CLASSES_ASSIGNED", "%1: client packet has been assigned to following classes: %2",
+    "DHCP6_CLASSES_ASSIGNED", "%1: client packet has been assigned to the following classes: %2",
     "DHCP6_CLASS_ASSIGNED", "%1: client packet has been assigned to the following class: %2",
     "DHCP6_CLASS_UNCONFIGURED", "%1: client packet belongs to an unconfigured class: %2",
     "DHCP6_CLASS_UNDEFINED", "required class %1 has no definition",
index 93a317defdd9efa27ea718ded4cbd1371d6e5df8..de4292ea3da10da341b2bd0d5c47176424e20bc9 100644 (file)
@@ -72,7 +72,7 @@ The server will continue to operate but won't make any further attempts
 to fetch configuration updates. The administrator must fix the configuration
 in the database and reload (or restart) the server.
 
-% DHCP6_CLASSES_ASSIGNED %1: client packet has been assigned to following classes: %2
+% DHCP6_CLASSES_ASSIGNED %1: client packet has been assigned to the following classes: %2
 This debug message informs that incoming packet has been assigned to specified
 classes. This is a normal behavior and indicates successful operation.
 The first argument specifies the client and transaction identification