-
Notifications
You must be signed in to change notification settings - Fork 42
feat: support installing the agent with TAR installer and the install subcommand #378
feat: support installing the agent with TAR installer and the install subcommand #378
Conversation
We refactored the installer install actions to delegate the execution to the installer instead of running it in the tests. We also added the new steps for the commands feature.
The life cycle (preInstall > install > enroll > postInstall) depends on the installer: - TAR leverages preInstall phase to extract the TAR file and create the proper layout - RPM and DEB leverage install phase to use package managers to install the artifact - TAR leverages install phase to actually install and enroll the agent - RPM and DEP needs an extra enrollment call - TAR defines an enroll method to be used outside the life cycle - RPM and DEB leverages postInstall phase to enable and run the service using systemd
} | ||
return nil | ||
} | ||
enrollFn := func(token string) error { |
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.
enroll is performed out of the box using install so this should not be necessary
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.
If you take a look, we are providing the enroll command for further usage in the re-enroll scenario. As defined in the life cycle (see PR description), we use install command to initial enroll, but enroll for following ones
@@ -1004,46 +1025,6 @@ func createDefaultHTTPRequest(url string) curl.HTTPRequest { | |||
} | |||
} | |||
|
|||
// createFleetPolicy() sends a POST request to Fleet creating a new test policy |
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 are not creating the policy because of elastic/kibana#81236
🐛 Flaky test report❕ There are test failures but not known flaky tests. Test stats 🧪
|
@@ -94,7 +94,7 @@ Scenario Outline: Un-installing the installed <os> agent | |||
And the "filebeat" process is in the "stopped" state on the host | |||
And the "metricbeat" process is in the "stopped" state on the host | |||
And the file system Agent folder is empty | |||
And the agent is listed in Fleet as "inactive" | |||
And the agent is listed in Fleet as "offline" |
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.
cc/ @EricDavisX
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.
It takes +2 minutes in reaching the offline
status. Is that correct?
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.
change LGTM
What does this PR do?
This PR adds the the TAR installer so that it's possible to install the agent from a TAR file. For that, we had to define a proper life cycle for agent commands (install, enroll), as depending on the installer type (RPM, DEB, TAR), the life cycle (preInstall > install > enroll > postInstall) depends on the installer:
preInstall:
TAR
leverages preInstall phase to extract the TAR file and create the proper layoutinstall:
RPM
andDEB
leverage install phase to use package managers to install the artifactTAR
leverages install phase to actually install and enroll the agentenroll:
RPM
andDEP
needs an extra enrollment callTAR
defines an enroll method to be used outside the lifepostInstall:
RPM
andDEB
leverages postInstall phase to enable and run the service using systemdThis PR also refactors the scenarios (feature files) merging the subcommand feature file with Fleet one. In these files, and for the sake of a green CI build, we are removing any interaction with the RPM and DEB installers, because we prefer the TAR install process. We could at any time turn them back as Outline examples in Gherkin:
Why is it important?
The first main thing is that the PR matches the e2e tests code with the Elastic Agent way of installing the agent, which is critical. The second thing, the tests pass locally and we expect to fix the tests on CI too.
Checklist
make notice
in the proper directory)How to test this PR locally
SUITE=fleet TAGS="fleet_mode" DEVELOPER_MODE=false TIMEOUT_FACTOR=3 LOG_LEVEL=TRACE make -C e2e functional-test
Related issues
Follow-ups
The test for uninstalling the agent is failing. Need to check. I pushed the PR to receive feedback from the team.
We could refactor the download of the agents and add it when installing the agent instead of at the beginning of the test suite. Why? Because we download them at that time to create a volume and mount it into the container, at startup. This is causing that, when running the tests in DEV mode (DEVELOPER_MODE=true) locally, where the services are not destroyed, docker-compose tries to reuse the service without recreating it (we are not using the
--force-recreate
option). Therefore, that installer is already there and could lead to unexpected errors because of garbage in the target container for the agent.