trident-acl-agent: add --validate-connection

[bfjelds]

Add --validate-connection <kubernetes|tridentd|nebraska> CLI flag that checks reachability of exactly one service based on trident-acl-agent config and exits immediately (0 on success, non-zero with a descriptive error on failure), instead of running the agent. Useful for on-node troubleshooting or a systemd ExecStartPre-style check without invoking the full orchestrator loop.

Unclear if this should merge or not.

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Adds a --validate-connection <kubernetes|tridentd|nebraska> mode to trident-acl-agent that performs a single dependency reachability check based on config/CLI overrides and then exits, instead of running the normal agent/orchestrator loop. This is aimed at on-node troubleshooting and systemd ExecStartPre-style preflight checks.

Changes:

• Introduces a ConnectionTarget clap ValueEnum and a new --validate-connection CLI flag.
• Implements validate_connection() to check Kubernetes (fetch Node), tridentd (connect gRPC socket), or Nebraska (run an Omaha update-check via spawn_blocking).
• Short-circuits main() to run the validation path and exit early when the flag is provided.

Suppressed comments (1)

crates/trident-acl-agent/src/main.rs:190

• spawn_blocking(...).await can fail with a JoinError for cancellation as well as panic. The current context string says the task "panicked", which may be inaccurate and confusing during troubleshooting.

            .await
            .context("Nebraska connectivity check task panicked")?
            .with_context(|| format!("failed to reach Nebraska server at {endpoint}"))?;

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (3)

crates/trident-acl-agent/src/main.rs:124

• The help text for ConnectionTarget::Nebraska says "only a network/transport failure is treated as unreachable", but the implementation also fails on non-success HTTP status codes (via error_for_status()) and malformed/non-Omaha responses (XML parse/protocol validation). This mismatch can mislead users about what failures to expect.

    /// Validates reachability of the Nebraska/Omaha server by issuing a real
    /// update-check query. Any well-formed Omaha response (including "no
    /// update available") counts as success - only a network/transport
    /// failure is treated as unreachable.

crates/trident-acl-agent/src/lib.rs:117

• check_nebraska_reachable() docs say it "only fails on network/transport problems" or malformed XML, but omaha::send() also treats non-success HTTP status codes as errors (via error_for_status()). The doc should reflect that it requires a successful HTTP response as well.

/// the Omaha protocol, without treating any app-level result (including a
/// non-OK app/update-check status) as a failure. Unlike [`query_for_update`],
/// this only fails on network/transport problems or a response that isn't
/// well-formed Omaha XML -- it's meant for a pure "can we talk to this
/// server at all" check (e.g. `--validate-connection nebraska`), not for

crates/trident-acl-agent/src/main.rs:194

• --validate-connection nebraska uses DEFAULT_NEBRASKA_TRACK instead of the configured [nebraska].track. This means the reachability check may exercise a different request than the agent will actually use (and could succeed/fail for the wrong reason), which contradicts the PR description that validation is based on the agent config.

                    &endpoint_for_task,
                    &app_id,
                    DEFAULT_NEBRASKA_TRACK,
                    IdSource::MachineIdHashed,
                )

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

crates/trident-acl-agent/src/main.rs:124

• The Nebraska help text says “Any well‑formed Omaha response … counts as success – only a network/transport failure is treated as unreachable”, but --validate-connection nebraska calls check_nebraska_reachable() which goes through omaha::send() and will fail on non‑2xx HTTP statuses (error_for_status()), even if the body is valid Omaha XML. This makes the CLI help misleading about what failures are expected.

Suggestion: either relax check_nebraska_reachable()/omaha::send() to parse valid Omaha XML even on non‑2xx responses, or (simpler) update this help text (and the check_nebraska_reachable docstring) to explicitly include HTTP status failures in the “unreachable” bucket.

    /// Validates reachability of the Nebraska/Omaha server by issuing a real
    /// update-check query. Any well-formed Omaha response (including "no
    /// update available") counts as success - only a network/transport
    /// failure is treated as unreachable.

crates/trident-acl-agent/src/main.rs:198

• The join error from spawn_blocking(...).await can also be caused by task cancellation (not only a panic). Using .context("... panicked") can produce a misleading error message.

Suggestion: use a more general message (or include the JoinError detail) so failures are accurately described.

            .await
            .context("Nebraska connectivity check task panicked")?
            .with_context(|| format!("failed to reach Nebraska server at {endpoint}"))?;