Remove the agent config file parameters for stand alone

[adam-stokes]

Signed-off-by: Adam Stokes [email protected]

What does this PR do?

This removes the volume mounting of elastic-agent.yml for fleet server stand alone. The side effect is that we will have to think about how we want to approach fleet mode outside of that. Currently in stand alone that config file is not useful and it causes device and resource errors when mounting inside of docker when operations within the elastic-agent occur.

I think for the other use cases we can tests integrations etc more dynamically than having elastic-agent.yml mounted as a volume. Thoughts?

Why is it important?

Testing standalone fleet server will fail if this configuration and volume exists

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 run the Unit tests for the CLI, and they are passing locally
• I have run the End-2-End tests for the suite I'm working on, and they are passing locally
• I have noticed new Go dependencies (run make notice in the proper directory)

Related issues

• Closes device or resource busy when attempting to load elastic-agent config in docker #981

Follow-ups

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Build Cause: Pull request #983 updated

• Start Time: 2021-04-08T08:57:34.804+0000

• Duration: 25 min 40 sec

• Commit: 2a36f11

Test stats 🧪

Test	Results
Failed	0
Passed	138
Skipped	0
Total	138

Trends 🧪

💚 Flaky test report

Tests succeeded.

Expand to view the summary

Test stats 🧪

Test	Results
Failed	0
Passed	138
Skipped	0
Total	138

[cachedout]

I'm not totally sure I follow the explanation of the original problem. Perhaps it would be good to file an issue with a more detailed explanation of the problem so that it's easier to put this PR in the proper context?

[mdelapenya]

I'd say it's not ok yet to remove the file from the e2e tests. If the original use case is to use what it's bundled into the image, we could move to an approach where we dockerCopy the file into the container only for PRs. Wdyt?

[adam-stokes]

I'd say it's not ok yet to remove the file from the e2e tests. If the original use case is to use what it's bundled into the image, we could move to an approach where we dockerCopy the file into the container only for PRs. Wdyt?

I think this only effects running fleet in stand alone mode. For all other scenarios we can use the volumes mount directive. I still don't know why docker gives us a resource busy error in stand alone mode when the elastic-agent.yml is modified though. But not using the volumes and doing a docker copy would workaround this issue, I just don't know if this is the right approach we should take.

Another idea would be to have 2 separate profiles, one for fleet and another for fleet in standalone mode.

[jalvz]

I think for the other use cases we can tests integrations etc more dynamically than having elastic-agent.yml mounted as a volume. Thoughts?

I like that, I generally think passing arguments is more flexible that mounting config files, + we don't need it for standalone.

[jalvz]

fyi I think you need to merge master to make tests pass.

[mdelapenya]

I've tested this PR locally and I think it's the right think to do, as explained in #981 (comment).

I'm going to merge it. Thanks for your work here!