Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iotedge check with confusing results #6901

Open
Suizi11 opened this issue Feb 10, 2023 · 5 comments
Open

iotedge check with confusing results #6901

Suizi11 opened this issue Feb 10, 2023 · 5 comments

Comments

@Suizi11
Copy link

Suizi11 commented Feb 10, 2023

Expected Behavior

When running the iotedge check --verbose I want to have some details WHY checks were skipped.

It would be nice when running iotedge check-list is executed that checks which are required for connectivity checks are "marked" somehow.

Current Behavior

Check without --verbose

check_iotedge_cmd="iotedge check --iothub-hostname prodIotHubNtuity.azure-devices.net --dont-run
    keyd-config-well-formed
    certd-config-well-formed
    tpmd-config-well-formed
    configs-up-to-date
    hostname
    aziot-version
    host-local-time
    identity-certificate-expiry
    est-identity-and-bootstrap-certificate-expiry
    local-ca-certificate-expiry
    certs-preloaded
    keyd-running
    certd-running
    tpmd-running
    identityd-running
    certs-read
    key-pairs-read
    est-server-https
    certs-match-private-keys
    host-connect-iothub-mqtt

    config-up-to-date
    container-engine-uri
    parent_hostname
    container-resolve-parent-hostname
    connect-management-uri
    aziot-edge-version
    container-local-time
    container-engine-dns
    container-engine-ipv6
    container-engine-logrotate
    edge-agent-storage-mounted-from-host
    edge-hub-storage-mounted-from-host
    check-agent-image
    proxy-settings

    container-default-connect-upstream-amqp
    container-default-connect-upstream-https
    container-default-connect-upstream-mqtt
    container-connect-upstream-mqtt
    "
eval $check_iotedge_cmd

Result:

Configuration checks (aziot-identity-service)
---------------------------------------------
√ identityd configuration is well-formed - OK

Connectivity checks (aziot-identity-service)
--------------------------------------------
√ host can connect to and perform TLS handshake with iothub AMQP port - OK
√ host can connect to and perform TLS handshake with iothub HTTPS / WebSockets port - OK
√ host can connect to and perform TLS handshake with DPS endpoint - OK

Configuration checks
--------------------
√ aziot-edged configuration is well-formed - OK

Connectivity checks
-------------------
5 check(s) succeeded.
2 check(s) were skipped due to errors from other checks. Re-run with --verbose for more details.

Check with --verbose delivers exactly the same result

Steps to Reproduce

Provide a detailed set of steps to reproduce the bug.

  1. Execute command shown in "current behavior"

Context (Environment)

Output of iotedge check

I found out that if special --dont-run are missing, the results are quite confusing. E.g. if I remove container-engine-uri then everything is clear.

Device Information

  • Host OS [e.g. Ubuntu 18.04, Windows Server IoT 2019]: CentOS 8 (RHEL 8)
  • Architecture [e.g. amd64, arm32, arm64]: amd64
  • Container OS [e.g. Linux containers, Windows containers]: Linux containers, of course

Runtime Versions

  • aziot-edged [run iotedge version]: 1.4.3
  • Edge Agent [image tag (e.g. 1.0.0)]: 1.4.7
  • Edge Hub [image tag (e.g. 1.0.0)]: 1.4.7
  • Docker/Moby [run docker version]: 20.10.11+azure-2

Note: when using Windows containers on Windows, run docker -H npipe:////./pipe/iotedge_moby_engine version instead

@micahl
Copy link
Contributor

micahl commented Feb 10, 2023

@Suizi11 I'm not sure I understand the issue. I tried iotedge check --verbose on a machine and see this output for the Connectivity checks:

...
Connectivity checks
-------------------
√ container on the default network can connect to upstream AMQP port - OK
√ container on the default network can connect to upstream HTTPS / WebSockets port - OK
√ container on the default network can connect to upstream MQTT port - OK
    skipping because of not required in this configuration
√ container on the IoT Edge module network can connect to upstream AMQP port - OK
√ container on the IoT Edge module network can connect to upstream HTTPS / WebSockets port - OK
√ container on the IoT Edge module network can connect to upstream MQTT port - OK
    skipping because of not required in this configuration
32 check(s) succeeded.
3 check(s) raised warnings.
2 check(s) were skipped due to errors from other checks.

Are you saying that when you add the '--verbose' flag you don't see anything like above where it says 'skipping because of ...'?

@Suizi11
Copy link
Author

Suizi11 commented Feb 13, 2023

@micahl you're right. Just execute the same command as in my "Current Behavior" section. There's no "skipping because of ...", although executed WITH --verbose. So, I've no clue which check has been skipped.

@micahl
Copy link
Contributor

micahl commented Feb 14, 2023

@Suizi11 Stepping back for a minute... why do you want to exclude running all of those checks?

@github-actions
Copy link

This issue is being marked as stale because it has been open for 30 days with no activity.

@Suizi11
Copy link
Author

Suizi11 commented Mar 23, 2023

@micahl I'm so sorry for this very, very late response

why: we've more than 5k devices in the field with 5k different local network conditions e.g. firewalls, that's why we execute a connectivity check regularly on the host level (OS), during this check we also want to iotedge check the connectivity to Azure IoT Hub to inform the customer if there's something not working within the local network

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants