[#2569] add JSON validation to code blocks in ARM

doc/sphinx/arm/agent.rst

@@ -44,7 +44,7 @@ Configuration
 
 The following example demonstrates the basic CA configuration.
 
-::
+.. code-block:: json
 
    {
        "Control-agent": {
@@ -78,7 +78,7 @@ The following example demonstrates the basic CA configuration.
                "d2": {
                    "socket-type": "unix",
                    "socket-name": "/path/to/the/unix/socket-d2"
-               },
+               }
            },
 
            "hooks-libraries": [

doc/sphinx/arm/dhcp4-srv.rst

@@ -2599,9 +2599,10 @@ sub-options.
 
 Finally, we can set values for the new options:
 
-::
+.. code-block:: json
 
-   "Dhcp4": {
+   {
+     "Dhcp4": {
        "option-data": [
            {
                "name": "subopt1",
@@ -2609,7 +2610,7 @@ Finally, we can set values for the new options:
                "space": "isc",
                "data": "192.0.2.3"
            },
-           }
+           {
                "name": "subopt2",
                "code": 2,
                "space": "isc",
@@ -2620,8 +2621,8 @@ Finally, we can set values for the new options:
                "code": 222,
                "space": "dhcp4"
            }
-       ],
+       ]
-       ...
+     }
    }
 
 It is possible to create an option which carries some data in
@@ -3752,12 +3753,11 @@ enables client identification using ``chaddr`` only. This instructs the
 server to ignore the client identifier during lease lookups and allocations
 for a particular subnet. Consider the following simplified server configuration:
 
-::
+.. code-block:: json
 
-   "Dhcp4": {
+   {
-       ...
+     "Dhcp4": {
        "match-client-id": true,
-       ...
        "subnet4": [
        {
            "subnet": "192.0.10.0/24",
@@ -3766,9 +3766,10 @@ for a particular subnet. Consider the following simplified server configuration:
        },
        {
            "subnet": "10.0.0.0/8",
-           "pools": [ { "pool": "10.0.0.23-10.0.2.99" } ],
+           "pools": [ { "pool": "10.0.0.23-10.0.2.99" } ]
        }
        ]
+     }
    }
 
 The ``match-client-id`` is a boolean value which controls this behavior.
@@ -4429,7 +4430,7 @@ The server qualifies the reserved hostname with the value of the
 ``ddns-qualifying-suffix`` parameter. For example, the following subnet
 configuration:
 
-::
+.. code-block:: json
 
        {
            "subnet4": [ {
@@ -4444,7 +4445,7 @@ configuration:
                ]
             }],
            "dhcp-ddns": {
-               "enable-updates": true,
+               "enable-updates": true
            }
        }
 
@@ -4456,7 +4457,7 @@ treated as a fully qualified name. Thus, by leaving the
 ``ddns-qualifying-suffix`` empty it is possible to qualify hostnames for
 different clients with different domain names:
 
-::
+.. code-block:: json
 
        {
            "subnet4": [ {
@@ -4475,7 +4476,7 @@ different clients with different domain names:
                ]
             }],
            "dhcp-ddns": {
-               "enable-updates": true,
+               "enable-updates": true
            }
        }
 
@@ -5476,13 +5477,13 @@ introduced:
                "subnet4": [
                    {
                        "subnet": "10.0.0.0/8",
-                       "pools": [ { "pool":  "10.0.0.1 - 10.0.0.99" } ],
+                       "pools": [ { "pool":  "10.0.0.1 - 10.0.0.99" } ]
                    },
                    {
                        "subnet": "192.0.2.0/24",
                        "pools": [ { "pool":  "192.0.2.100 - 192.0.2.199" } ]
                    }
-               ],
+               ]
            } ], # end of shared-networks
 
        # It is likely that in the network there will be a mix of regular,
@@ -5635,7 +5636,7 @@ shown in the example below.
            "subnet4": [
                {
                    "subnet": "10.0.0.0/8",
-                   "pools": [ { "pool":  "10.0.0.1 - 10.0.0.99" } ],
+                   "pools": [ { "pool":  "10.0.0.1 - 10.0.0.99" } ]
                },
                {
                     "subnet": "192.0.2.0/24",
@@ -5758,7 +5759,7 @@ following example:
                "subnet4": [
                    {
                        "subnet": "192.0.2.0/26",
-                       "pools": [ { "pool": "192.0.2.1 - 192.0.2.63" } ],
+                       "pools": [ { "pool": "192.0.2.1 - 192.0.2.63" } ]
                    },
                    {
                        "subnet": "10.0.0.0/24",
@@ -6013,18 +6014,20 @@ server is able to select this subnet for any incoming packets that come
 from a relay that has an address in the 192.0.2.0/24 subnet. It also
 selects that subnet for a relay with address 10.0.0.1.
 
-::
+.. code-block:: json
 
-   "Dhcp4": {
+   {
+     "Dhcp4": {
        "subnet4": [
            {
                "subnet": "192.0.2.0/24",
                "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
                "relay": {
                    "ip-addresses": [ "10.0.0.1" ]
-               },
+               }
            }
-       ],
+       ]
+     }
    }
 
 If ``relay`` is specified, the ``ip-addresses`` parameter within it is
@@ -7033,9 +7036,10 @@ Enabling the Configuration Backend
 Consider the following configuration snippet, which uses a MySQL configuration
 database:
 
-::
+.. code-block:: json
 
-   "Dhcp4": {
+   {
+     "Dhcp4": {
        "server-tag": "my DHCPv4 server",
        "config-control": {
            "config-databases": [{
@@ -7052,7 +7056,8 @@ database:
            "library": "/usr/local/lib/kea/hooks/libdhcp_mysql_cb.so"
        }, {
            "library": "/usr/local/lib/kea/hooks/libdhcp_cb_cmds.so"
-       }],
+       }]
+     }
    }
 
 The ``config-control`` command contains two parameters. ``config-databases``
@@ -7068,9 +7073,10 @@ merged into the configuration read from the configuration file.
 
 The following snippet illustrates the use of a PostgreSQL database:
 
-::
+.. code-block:: json
 
-   "Dhcp4": {
+   {
+     "Dhcp4": {
        "server-tag": "my DHCPv4 server",
        "config-control": {
            "config-databases": [{
@@ -7087,7 +7093,8 @@ The following snippet illustrates the use of a PostgreSQL database:
            "library": "/usr/local/lib/kea/hooks/libdhcp_pgsql_cb.so"
        }, {
            "library": "/usr/local/lib/kea/hooks/libdhcp_cb_cmds.so"
-       }],
+       }]
+     }
    }
 
 .. note::

doc/sphinx/arm/dhcp6-srv.rst

@@ -1787,12 +1787,12 @@ The S46 BR option is used to convey the IPv6 address of the Border
 Relay. This option is mandatory in the MAP-E Container option and is not
 permitted in the MAP-T and S46 Lightweight 4over6 Container options.
 
-::
+.. code-block:: json
 
    {
        "space": "s46-cont-mape-options",
        "name": "s46-br",
-       "data": "2001:db8:cafe::1",
+       "data": "2001:db8:cafe::1"
    }
 
 Another possible ``space`` value is ``s46-cont-lw-options``.
@@ -1804,12 +1804,12 @@ The S46 DMR option is used to convey values for the Default Mapping Rule
 (DMR). This option is mandatory in the MAP-T container option and is not
 permitted in the MAP-E and S46 Lightweight 4over6 Container options.
 
-::
+.. code-block:: json
 
    {
        "space": "s46-cont-mapt-options",
        "name": "s46-dmr",
-       "data": "2001:db8:cafe::/64",
+       "data": "2001:db8:cafe::/64"
    }
 
 This option must not be included in other containers.
@@ -1838,12 +1838,12 @@ S46 Port Parameters
 The S46 Port Parameters option specifies optional port-set information
 that may be provided to CEs.
 
-::
+.. code-block:: json
 
    {
        "space": "s46-rule-options",
        "name": "s46-portparams",
-       "data": "2, 3/4",
+       "data": "2, 3/4"
    }
 
 Another possible ``space`` value is ``s46-v4v6bind``, to include this option
@@ -2200,9 +2200,10 @@ sub-options.
 
 Finally, we can set values for the new options:
 
-::
+.. code-block:: json
 
-   "Dhcp6": {
+   {
+     "Dhcp6": {
        "option-data": [
            {
                "name": "subopt1",
@@ -2210,7 +2211,7 @@ Finally, we can set values for the new options:
                "space": "isc",
                "data": "2001:db8::abcd"
            },
-           }
+           {
                "name": "subopt2",
                "code": 2,
                "space": "isc",
@@ -2221,8 +2222,8 @@ Finally, we can set values for the new options:
                "code": 102,
                "space": "dhcp6"
            }
-       ],
+       ]
-       ...
+     }
    }
 
 It is possible to create an option which carries some data in
@@ -2414,9 +2415,10 @@ DHCPv6 server. However, support is disabled by default. It can be
 enabled on a per-subnet basis using the ``rapid-commit`` parameter as
 shown below:
 
-::
+.. code-block:: json
 
-   "Dhcp6": {
+   {
+     "Dhcp6": {
        "subnet6": [
            {
                "subnet": "2001:db8:beef::/48",
@@ -2425,10 +2427,10 @@ shown below:
                     {
                         "pool": "2001:db8:beef::1-2001:db8:beef::10"
                     }
-                ],
+                ]
            }
-       ],
+       ]
-       ...
+     }
    }
 
 This setting only affects the subnet for which ``rapid-commit`` is
@@ -3893,9 +3895,10 @@ treated as a fully qualified name. Thus, by leaving the
 ``ddns-qualifying-suffix`` empty it is possible to qualify hostnames for
 different clients with different domain names:
 
-::
+.. code-block:: json
 
-   "subnet6": [
+   {
+     "subnet6": [
        {
            "subnet": "2001:db8:1::/48",
            "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -3907,9 +3910,10 @@ different clients with different domain names:
                }
            ]
        }
-   ],
+     ],
-   "dhcp-ddns": {
+     "dhcp-ddns": {
-       "enable-updates": true,
+         "enable-updates": true
+     }
    }
 
 The above example results in the assignment of the
@@ -4950,7 +4954,7 @@ then override its value in the subnet scope. For example:
                         "data": "2001:db8:cafe::1"
                     } ]
                }
-           ],
+           ]
        } ]
 
 In this example, there is a ``dns-servers`` option defined that is available
@@ -5024,7 +5028,7 @@ of what **NOT** to do:
                     # name in the other subnet should be "eth1".
                     # "interface": "eth1"
                }
-           ],
+           ]
        } ]
 
 To minimize the chance of configuration errors, it is often more convenient
@@ -5044,13 +5048,13 @@ shown in the example below.
            "subnet6": [
                {
                    "subnet": "2001:db8::/64",
-                   "pools": [ { "pool":  "2001:db8::1 - 2001:db8::ffff" } ],
+                   "pools": [ { "pool":  "2001:db8::1 - 2001:db8::ffff" } ]
                },
                {
                     "subnet": "3ffe:abcd::/64",
                     "pools": [ { "pool":  "3ffe:abcd::1 - 3ffe:abcd::ffff" } ]
                }
-           ],
+           ]
        } ]
 
 
@@ -5151,7 +5155,7 @@ subnet. A common mistake is to assume that the subnet that includes a client
 class is preferred over subnets without client classes. Consider the
 following example:
 
-::
+.. code-block:: json
 
    {
        "client-classes": [
@@ -5169,7 +5173,7 @@ following example:
                "subnet6": [
                    {
                        "subnet": "2001:db8:1::/64",
-                       "pools": [ { "pool": "2001:db8:1::20 - 2001:db8:1::ff" } ],
+                       "pools": [ { "pool": "2001:db8:1::20 - 2001:db8:1::ff" } ]
                    },
                    {
                        "subnet": "2001:db8:3::/64",

doc/sphinx/arm/hooks-cb-cmds.rst

@@ -864,7 +864,7 @@ database:
                    "option-data": [ {
                        "name": "sntp-servers",
                        "data": "2001:db8:1::1"
-                   } ],
+                   } ]
                }
            ],
            "remote": {

doc/sphinx/arm/hooks-ddns-tuning.rst

@@ -66,7 +66,7 @@ global expression for that subnet. An example subnet expression is shown below:
     "subnet4": [{
         "subnet": "192.0.2.0/24",
         "pools": [{
-            "pool": "192.0.2.10 - 192.0.2.20",
+            "pool": "192.0.2.10 - 192.0.2.20"
         } ],
 
         // This is a subnet-specific user context.
@@ -75,7 +75,7 @@ global expression for that subnet. An example subnet expression is shown below:
                 "hostname-expr": "'guest-'+Int8ToText(substring(pkt4.yiaddr, 0,1))+'-' \
                                           +Int8ToText(substring(pkt4.yiaddr, 1,2))+'-' \
                                           +Int8ToText(substring(pkt4.yiaddr, 2,3))+'-' \
-                                          +Int8ToText(substring(pkt4.yiaddr, 3,4))",
+                                          +Int8ToText(substring(pkt4.yiaddr, 3,4))"
             },
             "last-modified": "2017-09-04 13:32",
             "description": "you can put anything you like here",

doc/sphinx/arm/hooks-ha.rst

@@ -228,9 +228,11 @@ The following is an example of an HA server pair and Control Agent configuration
 for ``hot-standby`` with TLS.
 
 Server 1:
-::
 
-   "Dhcp4": {
+.. code-block:: json
+
+   {
+     "Dhcp4": {
        "hooks-libraries": [{
            "library": "/usr/lib/kea/hooks/libdhcp_lease_cmds.so",
            "parameters": { }
@@ -239,9 +241,9 @@ Server 1:
            "parameters": {
                "high-availability": [{
                    "this-server-name": "server1",
-                   "trust-anchor": /usr/lib/kea/CA.pem,
+                   "trust-anchor": "/usr/lib/kea/CA.pem",
-                   "cert-file": /usr/lib/kea/server1_cert.pem,
+                   "cert-file": "/usr/lib/kea/server1_cert.pem",
-                   "key-file": /usr/lib/kea/server1_key.pem
+                   "key-file": "/usr/lib/kea/server1_key.pem",
                    "mode": "hot-standby",
                    "heartbeat-delay": 10000,
                    "max-response-delay": 60000,
@@ -265,15 +267,18 @@ Server 1:
        "subnet4": [{
            "subnet": "192.0.3.0/24",
            "pools": [{
-               "pool": "192.0.3.100 - 192.0.3.250",
+               "pool": "192.0.3.100 - 192.0.3.250"
                }]
        }]
+     }
    }
 
 Server 2:
-::
 
-   "Dhcp4": {
+.. code-block:: json
+
+   {
+     "Dhcp4": {
        "hooks-libraries": [{
            "library": "/usr/lib/kea/hooks/libdhcp_lease_cmds.so",
            "parameters": { }
@@ -282,9 +287,9 @@ Server 2:
            "parameters": {
                "high-availability": [{
                    "this-server-name": "server2",
-                   "trust-anchor": /usr/lib/kea/CA.pem,
+                   "trust-anchor": "/usr/lib/kea/CA.pem",
-                   "cert-file": /usr/lib/kea/server2_cert.pem,
+                   "cert-file": "/usr/lib/kea/server2_cert.pem",
-                   "key-file": /usr/lib/kea/server2_key.pem
+                   "key-file": "/usr/lib/kea/server2_key.pem",
                    "mode": "hot-standby",
                    "heartbeat-delay": 10000,
                    "max-response-delay": 60000,
@@ -308,9 +313,10 @@ Server 2:
        "subnet4": [{
            "subnet": "192.0.3.0/24",
            "pools": [{
-               "pool": "192.0.3.100 - 192.0.3.250",
+               "pool": "192.0.3.100 - 192.0.3.250"
                }]
        }]
+     }
    }
 
 Control Agent on Server 1:
@@ -962,12 +968,13 @@ The corresponding server configuration, using advanced classification (and the
 ``member`` expression), is provided below. For brevity's sake, the HA hook
 library configuration has been removed from this example.
 
-::
+.. code-block:: json
 
-   "Dhcp4": {
+   {
+     "Dhcp4": {
        "client-classes": [{
            "name": "phones",
-           "test": "substring(option[60].hex,0,6) == 'Aastra'",
+           "test": "substring(option[60].hex,0,6) == 'Aastra'"
        }, {
            "name": "laptops",
            "test": "not member('phones')"
@@ -992,7 +999,6 @@ library configuration has been removed from this example.
            "library": "/usr/lib/kea/hooks/libdhcp_ha.so",
            "parameters": {
                "high-availability": [{
-                  ...
                }]
            }
        }],
@@ -1019,7 +1025,8 @@ library configuration has been removed from this example.
            }],
 
            "relay": { "ip-address": "10.1.2.3" }
-       }],
+       }]
+     }
    }
 
 The configuration provided above splits the address range into four pools: two
@@ -1126,9 +1133,10 @@ Passive-Backup Configuration
 The following is an example configuration file for the primary server in a
 ``passive-backup`` configuration:
 
-::
+.. code-block:: json
 
-   "Dhcp4": {
+   {
+     "Dhcp4": {
        "hooks-libraries": [{
            "library": "/usr/lib/kea/hooks/libdhcp_lease_cmds.so",
            "parameters": { }
@@ -1161,7 +1169,7 @@ The following is an example configuration file for the primary server in a
        "subnet4": [{
            "subnet": "192.0.3.0/24",
            "pools": [{
-               "pool": "192.0.3.100 - 192.0.3.250",
+               "pool": "192.0.3.100 - 192.0.3.250"
            }],
 
            "option-data": [{
@@ -1171,6 +1179,7 @@ The following is an example configuration file for the primary server in a
 
            "relay": { "ip-address": "10.1.2.3" }
        }]
+     }
    }
 
 The configurations of three peers are included: one for the primary and two for

doc/sphinx/arm/hooks-host-cmds.rst

@@ -463,12 +463,12 @@ The response will contain a list of hosts with updated ``source-index``
 and ``from`` fields. Continue calling the command until the last
 page is received. Its response will look like this:
 
-::
+.. code-block:: json
 
    {
        "arguments": {
            "count": 0,
-           "hosts": [ ],
+           "hosts": [ ]
        },
        "result": 3,
        "0 IPv4 host(s) found."

doc/sphinx/arm/hooks-stat-cmds.rst

@@ -113,14 +113,14 @@ The following command fetches lease statistics for subnet ID 10 from a
 The following command fetches lease statistics for all subnets with IDs
 in the range 10 through 50 from a ``kea-dhcp4`` server:
 
-::
+.. code-block:: json
 
    {
      "command": "stat-lease4-get",
      "arguments": {
        "subnet-range" {
          "first-subnet-id": 10,
-         "last-subnet-id": 50,
+         "last-subnet-id": 50
        }
      }
    }

doc/sphinx/arm/hooks-subnet-cmds.rst

@@ -841,7 +841,7 @@ and "delegated-len" parameters, the options are identified by the 'name' or
 'code' and 'space' parameters. The 'space' parameter can be omitted if the
 option belongs to the default 'dhcp6' space.
 
-::
+.. code-block:: json
 
    {
        "command": "subnet6-delta-del",
@@ -865,7 +865,7 @@ option belongs to the default 'dhcp6' space.
                    {
                        "prefix": "2001:db8:4::",
                        "prefix-len": 48,
-                       "delegated-len": 64,
+                       "delegated-len": 64
                    }
                ],
                "pools": [

doc/sphinx/arm/hooks.rst

@@ -305,14 +305,14 @@ The DDNS-Tuning Hook uses user-context to configure per subnet behavior. Example
     "subnet4": [{
         "subnet": "192.0.2.0/24",
         "pools": [{
-            "pool": "192.0.2.10 - 192.0.2.20",
+            "pool": "192.0.2.10 - 192.0.2.20"
         } ],
         "user-context": {
             "ddns-tuning": {
                 "hostname-expr": "'guest-'+Int8ToText(substring(pkt4.yiaddr, 0,1))+'-' \
                                           +Int8ToText(substring(pkt4.yiaddr, 1,2))+'-' \
                                           +Int8ToText(substring(pkt4.yiaddr, 2,3))+'-' \
-                                          +Int8ToText(substring(pkt4.yiaddr, 3,4))",
+                                          +Int8ToText(substring(pkt4.yiaddr, 3,4))"
             },
             "last-modified": "2017-09-04 13:32",
             "phones": [ "x1234", "x2345" ],

doc/sphinx/arm/lease-expiration.rst

@@ -133,18 +133,16 @@ processed in a single reclamation cycle, and the maximum amount of time
 a single reclamation cycle is allowed to run before being interrupted.
 The following examples demonstrate how these parameters can be used:
 
-::
+.. code-block:: json
-
-   "Dhcp4": {
-       ...
 
+   {
+     "Dhcp4": {
        "expired-leases-processing": {
            "reclaim-timer-wait-time": 5,
            "max-reclaim-leases": 0,
-           "max-reclaim-time": 0,
+           "max-reclaim-time": 0
-       },
+       }
-
+     }
-       ...
    }
 
 The first parameter is expressed in seconds and specifies an interval
@@ -182,19 +180,17 @@ apply restrictions to the maximum duration of a reclamation cycle or the
 maximum number of leases reclaimed in a cycle. The following
 configuration demonstrates how this can be done:
 
-::
+.. code-block:: json
-
-   "Dhcp4": {
-       ...
 
+   {
+     "Dhcp4": {
        "expired-leases-processing": {
            "reclaim-timer-wait-time": 3,
            "max-reclaim-leases": 100,
            "max-reclaim-time": 50,
-           "unwarned-reclaim-cycles": 10,
+           "unwarned-reclaim-cycles": 10
-       },
+       }
-
+     }
-       ...
    }
 
 In this example, the ``max-reclaim-leases`` parameter limits the number of leases