Skip to content
This repository has been archived by the owner on Sep 17, 2024. It is now read-only.

Add Kubernetes autodiscover test cases for standalone Agent #1090

Closed
jsoriano opened this issue Apr 26, 2021 · 4 comments · Fixed by #1645
Closed

Add Kubernetes autodiscover test cases for standalone Agent #1090

jsoriano opened this issue Apr 26, 2021 · 4 comments · Fixed by #1645
Assignees
Labels
area:test Anything related to the Test automation priority:medium Important work, but not urgent or blocking. size:M 1-5 days Team:Integrations Label for the Integrations team triaged Triaged issues will end up in Backlog column in Robots GH Project

Comments

@jsoriano
Copy link
Member

jsoriano commented Apr 26, 2021

Continue with #1064 to cover also autodiscover test cases with standalone Agent.

Current tests use the file output to write the events, if it is not possible to use this output with Agent we will need to refactor this part to write the events in Elasticsearch or other supported output.

// cc: @mdelapenya @ChrsMark

@jsoriano jsoriano added the Team:Integrations Label for the Integrations team label Apr 26, 2021
@jsoriano jsoriano changed the title Add Kubernetes autodiscover test cases for Agent Add Kubernetes autodiscover test cases for standalone Agent Apr 26, 2021
@adam-stokes adam-stokes added area:test Anything related to the Test automation priority:medium Important work, but not urgent or blocking. size:M 1-5 days triaged Triaged issues will end up in Backlog column in Robots GH Project labels Apr 29, 2021
@ChrsMark
Copy link
Member

ChrsMark commented Sep 23, 2021

I had a look into this and tried to figure out what is needed here. I see some possible blockers here:

  1. I'm assuming that we are gonna use standalone Agent for simplicity since we only want to test the internal functionality of the k8s provider.
  2. The tests for beats' autodiscovery follow a simplistic (but really handy) approach of writing the output to a file. Unfortunately this is not possible with elastic-agent since it does not support this output yet. So the only alternative is to write the output to ES.
  3. This brings us to the problem of where this ES could run. The best option would be to be deployed as a Pod so as to be in the same network with Agent's pod and be directly accessible. Is this doable within this framework though?
  4. Last but not least we would need to verify the events, most probably using the ES API?

@jsoriano @mdelapenya let me know what you think about the above and if this scenario would be reasonable and doable. Also any pointers on top of it are more than welcome.

@jsoriano
Copy link
Member Author

jsoriano commented Oct 5, 2021

Hey @ChrsMark, thanks for looking into this. Yes, I agree with your assumptions, we should simplify the deployment using standalone Agent, and if Agent is only able to output to ES, we are going to need a ES deployed.
Also for simplicity, this ES could be deployed as a single node in a pod in the same K8s cluster where the test is run, then the output of the Agent could be configured to use this node, and events could be collected from there with HTTP requests.
Maybe this ES pod can be even part of the Agent manifest, or even a container in the same pod. Then current framework could be enough, though it will take a bit more of time to start 🙂 With this we would only need to add something to retrieve and check the collected events.

@ChrsMark
Copy link
Member

ChrsMark commented Oct 7, 2021

Thanks for your feedback @jsoriano. I tried to add a simple case at #1645 and it seems to work. Only tricky part is that I use a background script to fetch events from ES api and write them to the expected file. Other option would be to tune the suite so as to be able to fetch/check events directly from ES but I'm not sure what effort it would require. Let me know what you think.

@jsoriano
Copy link
Member Author

jsoriano commented Oct 7, 2021

@ChrsMark if it works, I think we can start with this. If we see this trick is a burden to maintain we can reconsider in the future.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area:test Anything related to the Test automation priority:medium Important work, but not urgent or blocking. size:M 1-5 days Team:Integrations Label for the Integrations team triaged Triaged issues will end up in Backlog column in Robots GH Project
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants