... | @@ -47,9 +47,7 @@ Click around. As of 0.9 the BIND capabilities are basic. Stork is able to check |
... | @@ -47,9 +47,7 @@ Click around. As of 0.9 the BIND capabilities are basic. Stork is able to check |
|
|
|
|
|
Go to `Services`->`Machines` and click `Add New Machine`, type in `agent-kea`. The procedure is the same as before, but this time Stork detected Kea servers running. Notice that a problem is reported.
|
|
Go to `Services`->`Machines` and click `Add New Machine`, type in `agent-kea`. The procedure is the same as before, but this time Stork detected Kea servers running. Notice that a problem is reported.
|
|
|
|
|
|
Kea is being shipped with CA (Control Agent) preconfigured with control sockets for DHCPv4, DHCPv6 and DDNS. This simplifies deployment. CA tries to connect to all of those daemons and continues with only those that respond. That makes it easy to deploy daemons selectively. However, Stork looks at the CA config and determines that there are 3 daemons expected, but only DHCPv4 is running. Therefore it reports a problem of non-running DHCPv6 and DDNS daemons.
|
|
Kea is being shipped with CA (Control Agent) preconfigured with control sockets for DHCPv4, DHCPv6 and DDNS. This simplifies deployment. In this particular Kea deployment only DHCPv4 daemon is installed. CA tries to connect to all of those daemons and continues with only those that respond. That makes it easy to deploy daemons selectively. However, Stork looks at the CA config and determines that there are 3 daemons expected, but only DHCPv4 is running. The other ones are greyed out and on their tab there is information that Stork agent cannot communicate with them. As this is initial situation Stork concludes that this is as expected and switches of monitoring of these daemons, only DHCPv4 is monitored and its status is green.
|
|
|
|
|
|
Stork developers have several ideas how to deal with the situation, but we'd love to hear your thoughts on this. We could simply modify the docker container to run all daemons. This would nice feeling of seeing all green, but wouldn't demonstrate that Stork is able to detect problems. Second alternative would be to modify the CA config, so it would attempt only to connect to daemons that are actually running (DHCPv4 only). Third, we could add an **Ignore** or **That's ok** button that the user could click to indicate that it's ok that DHCPv6 or DDNS is not running. Ultimately, the network admin is the source of truth that knows whether the daemon is supposed to be running or not.
|
|
|
|
|
|
|
|
7. **Inspect Kea details**.
|
|
7. **Inspect Kea details**.
|
|
|
|
|
... | | ... | |