Initialize Paths before loading the keystore #10706
Conversation
|
@urso @kvch I would like your input here, due to a bug the location of the keystore was not clear and could have been created in the config dir instead of the data dir. So by making the above change, it ensures that the Keystore file is always created in the data dir. But after slack discussion maybe the real location of the keystore should be in the configuration directory next to the yaml. WDYT? |
|
Copying over from our chat, the issue arose when the default vs: The docs are currently clear that the keystore goes in the config dir but 7.0 is an opportunity to change this. https://www.elastic.co/guide/en/apm/server/current/keystore.html#creating-keystore. |
|
I think keystore should go under the data dir. It is a file manipulated by a Beat, so it is more similar to a registry file. Under the config folder, there are files which can be edited by users using a text editor of their choice. However, keystore is not intended to be modified via such tools, only using the Beat. |
|
@kvch It is indeed a file manipulated by the beat CLI, but at the same time creating a file on a single host and deploy it to multiple machines is a possibility. |
|
@ph True. Then I agree with you, it should go under the dir config. |
The paths were incorrectly initialized meaning that instead of creating the keystore in the data directory it was created next to the binary. The problem was the call to `paths.InitPaths()` was done after loading the keystore, this was causing a chicken and egg situation and `paths.Resolve(path.Data, "hello")` was returning "hello" instead of `data/hello`. To solve that situation we do a partial extract of the configuration, just enough to initialize the paths and we move on to the keystore and the complete unpack.
|
Ok, I will do the path change in another PR, this still need to go in and it will make sure the data path is correctly respected. |
ph
force-pushed
the
fix/correctly-initialize-paths-before-keystore
branch
from
cf2933a
to
fb1949b
Compare
|
rebased on top of master. |
* Initialize Paths before loading the keystore The paths were incorrectly initialized meaning that instead of creating the keystore in the data directory it was created next to the binary. The problem was the call to `paths.InitPaths()` was done after loading the keystore, this was causing a chicken and egg situation and `paths.Resolve(path.Data, "hello")` was returning "hello" instead of `data/hello`. To solve that situation we do a partial extract of the configuration, just enough to initialize the paths and we move on to the keystore and the complete unpack. (cherry picked from commit 3dbc233)
graphaelli
added
v7.0.0
and removed
needs_backport
…re (#11325) * Initialize Paths before loading the keystore (#10706) * Initialize Paths before loading the keystore The paths were incorrectly initialized meaning that instead of creating the keystore in the data directory it was created next to the binary. The problem was the call to `paths.InitPaths()` was done after loading the keystore, this was causing a chicken and egg situation and `paths.Resolve(path.Data, "hello")` was returning "hello" instead of `data/hello`. To solve that situation we do a partial extract of the configuration, just enough to initialize the paths and we move on to the keystore and the complete unpack. (cherry picked from commit 3dbc233) * Update CHANGELOG.next.asciidoc
* Initialize Paths before loading the keystore The paths were incorrectly initialized meaning that instead of creating the keystore in the data directory it was created next to the binary. The problem was the call to `paths.InitPaths()` was done after loading the keystore, this was causing a chicken and egg situation and `paths.Resolve(path.Data, "hello")` was returning "hello" instead of `data/hello`. To solve that situation we do a partial extract of the configuration, just enough to initialize the paths and we move on to the keystore and the complete unpack. (cherry picked from commit 3dbc233)
…re (#11497) Cherry-pick of PR #10706 to 6.7 branch. Original message: The paths were incorrectly initialized meaning that instead of creating the keystore in the data directory it was created next to the binary. The problem was the call to `paths.InitPaths()` was done after loading the keystore, this was causing a chicken and egg situation and `paths.Resolve(path.Data, "hello")` was returning "hello" instead of `data/hello`. To solve that situation we do a partial extract of the configuration, just enough to initialize the paths and we move on to the keystore and the complete unpack.
The paths were incorrectly initialized meaning that instead of creating
the keystore in the data directory it was created next to the binary.
The problem was the call to
paths.InitPaths()was done after loadingthe keystore, this was causing a chicken and egg situation and
paths.Resolve(path.Data, "hello")was returning "hello" instead ofdata/hello.To solve that situation we do a partial extract of the configuration,
just enough to initialize the paths and we move on to the keystore and
the complete unpack.