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

Add aziot check #83

Merged
merged 41 commits into from
Jan 7, 2021
Merged

Add aziot check #83

merged 41 commits into from
Jan 7, 2021

Conversation

daprilik
Copy link
Contributor

@daprilik daprilik commented Dec 8, 2020

Adds a new aziot check subcommand to aziot, modeled after iotedge check.

Should be reviewed in conjunction with the upstream PR at Azure/iotedge#4153

Please note that the aziot check implementation is not a straight copy-paste from iotedge check, and while the two implementations have a lot in common, aziot check's underlying check framework has been substantially refactored, simplified, and modernized. Notable changes include the use of async_trait on the Check trait, the use of serde_erased to simplify checker serialization, and removing all the Windows console specific text formatting code.

While the internals of aziot check are quite different from iotedge check, I've made sure that the user-facing text and json output formats have remained exactly the same between the two tools.

One notable addition to aziot check is the new json-stream output format, which will enable iotedge check to invoke iotedge check as a sub-process. Aside from streamlining check flow (users won't have to invoke both check commands separately), the additional_info payload will be used to share certain bits of provisioning-specific information with iotedge that it wouldn't otherwise have access to (e.g: the iothub_hostname configuration option used in the host connectivity checks in iotedge check is part of the identityd config, which iotedge should not be able to access directly).


This PR should be reviewed along two axes:

  1. The aziot check subcommand, framework, and implementation quality
  2. The actual checks themselves

The checks are divided into two categories:

  1. Checks ported over from iotedge check (due to certain functionality being moved down the stack into aziot)
    • host_connect_dps_endpoint
    • host_local_time
    • hostname
    • identity_certificate_expiry
    • well_formed_configs
  2. New checks specific to the new aziot architecture
    • certs_preloaded
    • dameons_running

While the primary goal of this PR is to get aziot check "up and running" in an effort to fix iotedge check, if there are any checks that I may have missed that are "critical" to merge as part of this initial PR, please let me know.


This PR will be un-drafted once the corresponding iotedge check PR has been submitted, as there's a non-zero chance the json-streaming output format will require changes as part of the integration work.

@daprilik daprilik requested review from massand and arsing December 8, 2020 18:41
Copy link
Contributor

@massand massand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM so far. Few comments

aziot/src/internal/check/additional_info.rs Show resolved Hide resolved
aziot/src/internal/check/additional_info.rs Outdated Show resolved Hide resolved
shared: &CheckerShared,
_cache: &mut CheckerCache,
) -> Result<CheckResult> {
// TODO: check against parent time in nested edge scenarios
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IS doesn't have any knowledge of nested edge so far. Edge does have awareness of the parent_hostname configuration and hence nested edge.

Copy link
Contributor Author

@daprilik daprilik Dec 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewing my notes, I actually have no idea why I left this TODO...
The original host_local_time check doesn't even do that. https://github.com/Azure/iotedge/blob/release/1.0.10/edgelet/iotedge/src/check/checks/host_local_time.rs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, well, now I remember why I left this TODO... I accidentally liked to an older version of the check from before nested-edge. The latest version does include some extra logic in nested-edge scenarios:
https://github.com/Azure/iotedge/blob/release/1.2/edgelet/iotedge/src/check/checks/host_local_time.rs#L41-L46

So, what should we do to account for that extra logic?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The nested check seems strange because the root node of the nested edge topology would still need to be in sync with NTP (to connect to IoT Hub). All child nodes down the chain would then be transitively in sync with NTP. IS does not have the concept of parent_hostname because the parent hostname is the iothub_hostname. So, the NTP check is good enough for both cases in IS and you can remove the parent_hostname time check altogether.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, that's what I like to hear 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need both the NTP check and the HTTP Date header check in IS. If IS (and thus the check) doesn't know it's running in a nested scenario, the check might have to try NTP and then fall back to the HTTP Date header method.

@massand I don't understand what you mean by "all child nodes down the chain would then be transitively in sync with NTP."

aziot/src/internal/check/checks/mod.rs Show resolved Hide resolved
still a lot of room for improvement, but this seems like a reasonable
foundation.
unfortunately, anyhow doesn't supporting using the `backtrace` crate for
backtraces on stable, relying on the currently unstable std::backtrace
instead.
this is basically a straight copy/paste, aside from the removal of
Failure for error handling.
oh boy, I sure did go down a rabbit hole trying to support "nested"
checks. let me tell ya - it's not trivial, and will require substantial
changes to the code in `check.rs`. I'm not too keen on doing that right
now, so I'm pushing it away for later.

also, I realized that its' probably a _bad_ idea to rely on the cert
service actually running to fetch certificates. as such, checks will
now directly read certificates from disk.
wow there was _very_ little documentation on how to perform a TLS
handshake with hyper_openssl. Turns out you have to treat the
HttpsConnector as a hyper::Service, and then `.call()` it, thereby
getting back a handshake future. There are _zero_ docs which describe
this, and the only reason I figured it out was by crossreferencing the
hyper_openssl implementation with hyper_tls.
this will un-break some of the iotedge check checks.
enables 'iotedge check-list' to list aziot checks as well.
this new crate is consumed by `iotedge check`, and ensures the two tools
stay in-sync.
Copy link
Contributor

@massand massand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

aziot/Cargo.toml Outdated Show resolved Hide resolved
aziot/Cargo.toml Outdated Show resolved Hide resolved
aziot/src/main.rs Outdated Show resolved Hide resolved
aziot/src/main.rs Show resolved Hide resolved
aziot/src/check.rs Outdated Show resolved Hide resolved
aziot/src/internal/check/mod.rs Outdated Show resolved Hide resolved
aziot/src/internal/check/mod.rs Outdated Show resolved Hide resolved
aziot/src/internal/common.rs Show resolved Hide resolved
identity/aziot-identityd-config/src/lib.rs Outdated Show resolved Hide resolved
mini-sntp/src/lib.rs Outdated Show resolved Hide resolved
@daprilik daprilik requested a review from arsing January 5, 2021 21:51
- removed internal check::prelude
- removed some unused imports found using `cargo udeps`
- other tweaks
aziot/src/internal/check/checks/host_connect_iothub.rs Outdated Show resolved Hide resolved
cert/aziot-certd-config/src/util.rs Show resolved Hide resolved
aziot/src/internal/check/mod.rs Show resolved Hide resolved
@daprilik daprilik requested a review from arsing January 7, 2021 22:50
@kodiakhq kodiakhq bot merged commit a344cfa into Azure:main Jan 7, 2021
@daprilik daprilik deleted the aziot-check branch January 22, 2021 16:33
kodiakhq bot pushed a commit to Azure/iotedge that referenced this pull request Jan 22, 2021
Updates `iotedge check` to work with the new underlying `aziot` architecture.

This PR builds on-top of the functionality introduced in the downstream `aziot` PR at Azure/iot-identity-service#83

* * *

In a nutshell, many of the checks that used to be in `iotedge check` have been ported over into the new `aziot check` tool. Please see the associated downstream PR for more details. That being said, we don't want to make users invoke multiple `check` commands, so this PR also includes functionality whereby `iotedge` will shell-out to `aziot` when running `check` and `check-list`, transparently displaying `aziot`'s check results alongside `iotedge`-specific checks.

As with the downstream PR, this PR should be reviewed along two axes:

1. Refactoring work around the actual `iotedge check/check-list` subcommands
2. The actual checks themselves (i.e: confirming that all removed checks have indeed been migrated / aren't applicable anymore).

I would **really appreciate it** if the reviewers actually pulled these changes locally and tested them out, as subtle things such as check output formatting and/or checking check pass/failure cases aren't easy to spot by looking at the code alone.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants