-
Notifications
You must be signed in to change notification settings - Fork 46
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
Add aziot check
#83
Conversation
There was a problem hiding this 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
shared: &CheckerShared, | ||
_cache: &mut CheckerCache, | ||
) -> Result<CheckResult> { | ||
// TODO: check against parent time in nested edge scenarios |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 😄
There was a problem hiding this comment.
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."
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.
c2b1d87
to
be1c1db
Compare
this new crate is consumed by `iotedge check`, and ensures the two tools stay in-sync.
731c130
to
1ac11e7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- removed internal check::prelude - removed some unused imports found using `cargo udeps` - other tweaks
this will require an update to the upstream iotedge check PR as well
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.
Adds a new
aziot check
subcommand toaziot
, modeled afteriotedge 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 fromiotedge 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 ofasync_trait
on theCheck
trait, the use ofserde_erased
to simplify checker serialization, and removing all the Windows console specific text formatting code.While the internals of
aziot check
are quite different fromiotedge check
, I've made sure that the user-facingtext
andjson
output formats have remained exactly the same between the two tools.One notable addition to
aziot check
is the newjson-stream
output format, which will enableiotedge check
to invokeiotedge check
as a sub-process. Aside from streamlining check flow (users won't have to invoke bothcheck
commands separately), theadditional_info
payload will be used to share certain bits of provisioning-specific information withiotedge
that it wouldn't otherwise have access to (e.g: theiothub_hostname
configuration option used in the host connectivity checks iniotedge check
is part of theidentityd
config, whichiotedge
should not be able to access directly).This PR should be reviewed along two axes:
aziot check
subcommand, framework, and implementation qualityThe checks are divided into two categories:
iotedge check
(due to certain functionality being moved down the stack intoaziot
)host_connect_dps_endpoint
host_local_time
hostname
identity_certificate_expiry
well_formed_configs
aziot
architecturecerts_preloaded
dameons_running
While the primary goal of this PR is to get
aziot check
"up and running" in an effort to fixiotedge 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 thejson-streaming
output format will require changes as part of the integration work.