Restrict synthetics/browser from fleet #25831
Closed
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
We do not yet have a synthetics fleet image available, so, for now, users should not be allowed to create synthetics inputs in fleet. See elastic#22932 (comment)
andrewvc
added
enhancement
Team:obs-ds-hosted-services
|
Pinging @elastic/uptime (Team:Uptime) |
botelastic
bot
added
needs_team
💔 Build Failed
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪Log outputExpand to view the last 100 lines of log output
💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
|
location is fine but if you want to pack it into a resulting package |
|
@michalpristas updated per your suggestions. Is there any way we can test this PR prior to rolling out the fleet package? |
| @@ -45,6 +45,10 @@ shared: | |||
| source: 'elastic-agent.yml' | |||
| mode: 0600 | |||
| config: true | |||
| /etc/{{.BeatName}}/capabilities.yml: | |||
There was a problem hiding this comment.
this needs to be added in multiple places.
try searching for 'elastic-agent.yml' there should be 5 occurences, you have 1 so far.
|
This pull request is now in conflicts. Could you fix it? 🙏 |
|
I wonder if this is the right approach to follow. So far we don't have any capabilities file shipped by default and it is up to the user to create one if needed. No matter what the user configures in the capabilities.yml, synthetics/browser will not work so it should be hardcoded in the build. My understanding is the the only build that supports synthetics/browser is the complete Dockerfile. Instead of doing modifications to the capabilities, instead heartbeat should return an error if this input is sent down and explain to the user that it is not supported. It is not up to Elastic Agent to know if the input is working in a certain environment or not but heartbeat. My proposal is to move this implementation to heartbeat and not touch capabilities.yml file as it is not designed for this use case. |
|
Closing this based on Ruflin's concerns and the fact that we already do surface an error message in heartbeat interviews to run browser-based monitors if we are not running on an image with the synthetics dependencies. |
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.
We do not yet have a synthetics fleet image available, so, for now, users should not be allowed to create synthetics inputs in fleet.
@michalpristas can you verify that this is the right place for this file to exist? Once we have a special big docker image with synthetics deps we can conditionally remove this restriction in that special image (which has access to real browsers and graphics libs).
Fixes #25775
See also #22932 (comment)
Checklist
- [ ] My code follows the style guidelines of this project- [ ] I have made corresponding changes to the documentation- [ ] I have added tests that prove my fix is effective or that my feature worksCHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.How to test this PR locally
Not yet possible until elastic/uptime#276 is ready