Fix container paths config

[ycombinator]

What does this PR do?

This PR fixes the parsing of paths from the container-paths.yml file used internally when elastic-agent container is run.

Why is it important?

So the expected paths are loaded from container-paths.yml.

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

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

[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

• Start Time: 2023-04-17T20:24:08.471+0000

• Duration: 16 min 12 sec

Test stats 🧪

Test	Results
Failed	0
Passed	5531
Skipped	19
Total	5550

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages.

• run integration tests : Run the Elastic Agent Integration tests.

• run end-to-end tests : Generate the packages and run the E2E Tests.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[blakerouse]

Looks good!

[cmacknz]

Is there an issue we can link this to? I assume this is a follow up from #2330 for #2315?

I want to make sure we know what bug this is fixing so we can make sure it gets tested properly. If it's linked to #2315 then the test is that Heartbeat is able to start under the conditions described in that issue.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	98.529% (67/68)	👍
Files	68.22% (161/236)	👍
Classes	67.785% (303/447)	👍
Methods	54.052% (927/1715)	👍 0.058
Lines	39.625% (10503/26506)	👍 0.091
Conditionals	100.0% (0/0)	💚

[ycombinator]

Is there an issue we can link this to? I assume this is a follow up from #2330 for #2315?

I want to make sure we know what bug this is fixing so we can make sure it gets tested properly. If it's linked to #2315 then the test is that Heartbeat is able to start under the conditions described in that issue.

There's no issue per se that this PR fixes, at least not an issue that's been filed in GitHub. I noticed the incorrect struct tags as part of investigating #2315. But the actual fix for #2315 is #2330.

[cmacknz]

Thanks, no opposition to the change I just want to understand any intended (or unintended) consequences.

[ycombinator]

I just want to understand any intended (or unintended) consequences.

Thanks for calling this out. I did some testing as well as digging into the PR that introduced the /usr/share/elastic-agent/container-paths.yml file: elastic/beats#25204.

From reading that PR and the issue it fixed (elastic/beats#24956), I understand why the file is used for persisting the state path - so that commands like elastic-agent status can "find" the state directory (and the elastic-agent-control.sock socket file thereafter). However, I haven't been able to figure why other paths, i.e. the logs path and the config path, are also being persisted in the /usr/share/elastic-agent/container-paths.yml file.

Put another way, after I started up an Elastic Agent container and deleted the /usr/share/elastic-agent/container-paths.yml file, running elastic-agent status inside that container did not work, as expected, because the state path is no longer persisted. But what else should be breaking because the logs path and config path are no longer persisted either? I think answering this question would help figure out the consequences of the changes in this PR here.

@blakerouse Can you help answer the above question?

[jlind23]

@blakerouse @ycombinator bumping this just to avoid stalle PRs

[blakerouse]

@ycombinator I provided some input over Slack, but didn't add it to this PR.

I took another look at this and I believe that the config_path and log_path are still important and required.

The config_path is needed by the inspect command, otherwise it will not find the configuration. The log_path is needed for the diagnostics command or it would not be able to gather the logs for the diagnostics bundle.

[ycombinator]

Thanks @blakerouse. I started to test this PR by comparing the outputs of elastic-agent status, elastic-agent inspect, and elastic-agent diagnostics (specifically the logs folder in the bundle) from this PR's build with a build from main. Unfortunately, while doing this, I found a bug: #2470. So I have to wait until that bug is resolved before resuming testing on this PR.

[pierrehilbert]

@ycombinator do we need another round of review here?

[ycombinator]

@ycombinator do we need another round of review here?

@pierrehilbert Not yet. It's on my plate to test the changes in this PR; I just haven't gotten around to it yet (this PR is lower priority than some of the other things on my plate).

[ycombinator]

/test

[ycombinator]

I started to test this PR by comparing the outputs of elastic-agent status, elastic-agent inspect, and elastic-agent diagnostics (specifically the logs folder in the bundle) from this PR's build with a build from main.

I got around to testing this PR again, as described above. I see no differences when running the three commands using a build from this PR vs. using a build from main.

I also tested running the Agent as a Docker container, pausing/unpausing it and stopping/starting it. I did this with the build from the PR as well as the build from main and, again, I see no differences in behavior.

So I don't believe this PR will introduce any intended or unintended consequences.