Add `--dry-run` option to `enroll` sub-command

elastic / elastic-agent

Elastic Agent - single, unified way to add monitoring for logs, metrics, and other types of data to a host.

Other

124 stars 134 forks source link

Add `--dry-run` option to `enroll` sub-command #4881

Open ycombinator opened 3 months ago

ycombinator commented 3 months ago

Describe the enhancement:

Add a --dry-run CLI option to the enroll sub-command that tests Elastic Agent's connectivity to Fleet Server.

Describe a specific use case for the enhancement or feature:

To help users test Agent connectivity to Fleet Server before attempting to enroll.

What is the definition of done?

[ ] The enroll sub-command supports a new --dry-run CLI option
[ ] When this option is used, Agent should attempt to establish a connection to Fleet Server but not actually enroll the Agent.
[ ] If there are any issues with successfully connecting to Fleet Server, e.g. TLS, the command should failed with detailed output.

elasticmachine commented 3 months ago

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

cmacknz commented 3 months ago

Thinking more about this I'm not sure I like the idea of doing this with a --dry-run flag, we either have to change the enroll API endpoint which limits which agents are compatible with it, or we have to hit a consequence free endpoint and what the command does is misleading.

I think it may be better if we implement a test command that can hit each of the three network locations agent needs to function. These are:

elastic-agent test output that connects to the output in the policy and prints detailed information about what happened.
elastic-agent test fleet [options] that contacts Fleet Server with the options provided, or if already enrolled makes a test request using the options persisted in the agent encrypted store.
elastic-agent test download that contacts the binary download source and prints detailed information about what happened.

We could have diagnostics attempt each of these by default, with a configurable timeout, and an option to skip these checks.

nimarezainia commented 3 months ago

Great idea. Why is this a test command or flag. Perhaps these can be a set of checklists the agent goes through when it is being installed. It's validating the initial config. If any fail we fail installation with a decent warning message to the user. Of course we are only testing here against is what's in the boostrapping config elastic-agent.yml , the first policy download may bring a lot more configuration options.

cmacknz commented 3 months ago

Making this a structured set of tests that happens by default is a much better idea than making it an option set of tests.

When you enroll as part of installing, we validate we can reach fleet server, but we do nothing to validate the download source or the output before finishing the install.