-
Notifications
You must be signed in to change notification settings - Fork 148
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
Revert "Revert "Fix log level value reported by Agent to Fleet (#4838)" (#4938)" #4941
Revert "Revert "Fix log level value reported by Agent to Fleet (#4838)" (#4938)" #4941
Conversation
…ic#4838)" (elastic#4938)" This reverts commit 2b2e8d0.
This pull request does not have a backport label. Could you fix it @pchila? 🙏
NOTE: |
Quality Gate passedIssues Measures |
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
defer cancel() | ||
err := info.KibanaClient.DeletePolicy(timeoutCtx, policyResp.ID) | ||
assert.NoError(t, err, "error deleting policy %s", policyResp.ID) | ||
installOutput, err := f.Install(ctx, &atesting.InstallOpts{ |
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.
That you now install the agent is the problem, it doesn't set the paths correctly for the DEB and RPM agents #4929 (comment)
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.
(this is a bug in the test framework)
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.
How installing an agent in a separate test that does not run on the same machines as the .deb and .rpm tests could cause a failure in those tests?
Maybe you mean that adding a client to a an agent command (including those installed via rpm and dpkg) would cause issues in the .deb and rpm tests ?
Also in the previous version I've noticed that using a standalone command could not work as enroll forces a restart of the agent make the cmd.Wait()
call hang indefinitely on windows as the initial process had already completed
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.
I possibly misread exactly what is going on in this test, but the setup of the agent workDir used to execute agent commands in the fixture is wrong for DEB and RPM agents.
This reverts commit 2b2e8d0.
What does this PR do?
This PR reverts the revert of PR #4838.
The only difference compared to the original PR is the removal of agent client initialization in
(f *Fixture) PrepareAgentCommand
which was no longer needed once integration testTestSetLogLevelFleetManaged
usedinstall
instead ofrun
subcommand to run and enroll the agentWhy is it important?
We still want to send the correct log level in use by elastic agent to Fleet during check-in
Checklist
[ ] My code follows the style guidelines of this project[ ] I have commented my code, particularly in hard-to-understand areas[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files[ ] I have added tests that prove my fix is effective or that my feature works[ ] I have added an entry in./changelog/fragments
using the changelog tool[ ] I have added an integration test or an E2E testDisruptive User Impact
How to test this PR locally
Related issues
log_level
metadata is not accurate #4747Questions to ask yourself