Incorrect usage of `-w` for ping

[Nobuto Murata]

In config.yaml:

  ping_timeout:
    default: 2
    description: Timeout in seconds per ICMP request
    type: int

It suggests the timeout is *per request*. However, if ping_tries is set like 10 for example, the actual command will be executed is `ping -c 10 -w 2`. And it fails always because ping will exit before sending 10 packets because of `-w` as documented:

> -w deadline
> Specify a timeout, in seconds, before ping exits regardless
> of how many packets have been sent or received.

$ ping -c 10 -w 2 192.168.1.1; echo "return value: $?"
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=5.48 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=4.35 ms

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 4.353/4.916/5.479/0.563 ms

return value: 1

[src/lib/charms/layer/magpie_tools.py]
    ping_string = "ping -c {} -w {} {} {} > /dev/null 2>&1"\

I suppose the expected option here is `-W` (capital w).

> -W timeout
> Time to wait for a response, in seconds.

[Samuel Allan (samuelallan)]

> I suppose the expected option here is `-W` (capital w).

Either that, or the docs are incorrect? I guess it comes down to what behaviour do you want here?

[Samuel Allan (samuelallan)]

https://review.opendev.org/c/openstack/charm-magpie/+/841826

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/charm-magpie/+/841826
Committed: https://opendev.org/openstack/charm-magpie/commit/ca6b68cf4198ed9656c86b4c124785f97f098f24
Submitter: "Zuul (22348)"
Branch: master

commit ca6b68cf4198ed9656c86b4c124785f97f098f24
Author: Samuel Walladge <email address hidden>
Date: Mon May 16 11:32:00 2022 +0930

    Detect minor packet loss in ping step

    Improve how the ping check works to detect packet loss.
    Previously, the ping check would only fail
    with high packet loss situations.

    Add charm config for interval between sending ping packets,
    so we have more control for tuning if required.

    In the juju status output message,
    the percentage of packet loss will now be shown for each host
    if there was packet loss.
    Examples:

    - 100% loss (total failure): icmp failed: ['1: 100% packet loss']
    - some loss, but not total: icmp failed: ['1: 25% packet loss']
    - host 1 total failure, host 2 with some packet loss:
        icmp failed: ['1: 100% packet loss', '2: 25% packet loss']
    - all good: icmp ok

    Finally, drop the py35 tox test env,
    because python 3.5 is no longer supported.

    Closes-Bug: #1973606
    Closes-Bug: #1973659

    Change-Id: I50dbbf4d0e0df8f36b9eb63aedd69ddc845f167d