Re-enable resource leak tests, change timeout, improve message #4454
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fearful-symmetry
added
flaky-test
|
This pull request does not have a backport label. Could you fix it @fearful-symmetry? 🙏
NOTE: |
|
Pinging @elastic/elastic-agent (Team:Elastic-Agent) |
…aky-test-handle-leaks
|
In case you are missing the discussion in Slack, there was a change in 8.14.0-SNAPSHOT in Fleet that changed the output name from |
|
0.0% Duplication on New Code
rdner
approved these changes
Mar 22, 2024
juliaElastic
added a commit
to elastic/kibana
that referenced
this pull request
Mar 22, 2024
…arch type (#179218) ## Summary Related to #178857 and #177927 It seems that using output id instead of "default" in full agent policy had a higher impact than expected. There are a few places where agent relies on the name "default". ([This](elastic/elastic-agent#4454) and [this](elastic/elastic-agent#4453) pr) Because of this, doing a partial revert, to keep using "default" for elasticsearch output type to avoid breaking change. However, for other types, using the output id. This will fix the original issue of remote output health reporting. I think it is a rarely used feature to use a non-elasticsearch output as default, so it shouldn't have a big impact to not use "default" output name for those. To verify: - create a remote es output and set as default (both data and monitoring) - create an agent policy that uses default output - enroll an agent - expect that the agent sends system and elastic-agent metrics/logs to remote es - verify that the remote es health badge shows up on UI - set elasticsearch output back as default - verify that the agent policy has it as "default" in outputs section <img width="704" alt="image" src="https://github.com/elastic/kibana/assets/90178898/ab46b00d-efc2-49e1-ad7f-9acd44b2a9e5"> <img width="1251" alt="image" src="https://github.com/elastic/kibana/assets/90178898/a07c0d78-9126-43d9-bd0e-a4df193d7e78"> <img width="1791" alt="image" src="https://github.com/elastic/kibana/assets/90178898/868a054b-2cae-42f3-8f60-f2bff3b29efd"> <img width="715" alt="image" src="https://github.com/elastic/kibana/assets/90178898/721cd809-5f97-47e5-bf99-19f542d8ff83"> ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
pchila
reviewed
Mar 22, 2024
| allHealthy = false | ||
| } | ||
| } | ||
| return allHealthy && foundApache && foundSystem | ||
| }, runner.healthCheckTime, runner.healthCheckRefreshTime, "install never became healthy") | ||
| }, runner.healthCheckTime, runner.healthCheckRefreshTime, "install never became healthy: components did not return a healthy state: %s", compDebugName) |
There was a problem hiding this comment.
Nit: printing out the entire last agent status (in a structured way) may be more useful for debugging
pchila
approved these changes
Mar 22, 2024
juliaElastic
added a commit
to juliaElastic/kibana
that referenced
this pull request
Mar 26, 2024
…arch type (elastic#179218) ## Summary Related to elastic#178857 and elastic#177927 It seems that using output id instead of "default" in full agent policy had a higher impact than expected. There are a few places where agent relies on the name "default". ([This](elastic/elastic-agent#4454) and [this](elastic/elastic-agent#4453) pr) Because of this, doing a partial revert, to keep using "default" for elasticsearch output type to avoid breaking change. However, for other types, using the output id. This will fix the original issue of remote output health reporting. I think it is a rarely used feature to use a non-elasticsearch output as default, so it shouldn't have a big impact to not use "default" output name for those. To verify: - create a remote es output and set as default (both data and monitoring) - create an agent policy that uses default output - enroll an agent - expect that the agent sends system and elastic-agent metrics/logs to remote es - verify that the remote es health badge shows up on UI - set elasticsearch output back as default - verify that the agent policy has it as "default" in outputs section <img width="704" alt="image" src="https://github.com/elastic/kibana/assets/90178898/ab46b00d-efc2-49e1-ad7f-9acd44b2a9e5"> <img width="1251" alt="image" src="https://github.com/elastic/kibana/assets/90178898/a07c0d78-9126-43d9-bd0e-a4df193d7e78"> <img width="1791" alt="image" src="https://github.com/elastic/kibana/assets/90178898/868a054b-2cae-42f3-8f60-f2bff3b29efd"> <img width="715" alt="image" src="https://github.com/elastic/kibana/assets/90178898/721cd809-5f97-47e5-bf99-19f542d8ff83"> ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Attempt to fix #4447.
This increases the timeout on the health check, and improves the error message. As to why the test is flaky, my best guess right now is that the 3-minute timeout just isn't long enough on windows. Plan is just to re-run the test a bunch of times and...see what happens.