-
Notifications
You must be signed in to change notification settings - Fork 41
feat: support running kibana with different configs #1644
feat: support running kibana with different configs #1644
Conversation
This will enable having multiple config files per test suite, using the profile abstraction: one dir per config with the profile name
It will represent the default profile
Default profile will be 'default'
The bootstrap method is called before the test suite (only once) AND before each test scenario, as it has been defined as a Background clause. If an scenario wants to configure a new config file for Kibana, a new profile file with the new kibana config must be created at the compose level, using the ProfileName as directory name.
💔 Tests Failed
Expand to view the summary
Build stats
Test stats 🧪
Test errors
Expand to view the tests failures
|
@@ -0,0 +1,20 @@ | |||
--- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nchaulet here it's the config file as a placeholder for your config
Not merging yet because I’ve started to see the following error when using elastic-package since today
I can reproduce it locally but only for this PR. Pinged @mtojek about that |
Taking a look |
I'm wondering if this problem isn't related to changes around Go 1.17.1 (cc @v1v). |
monitoring.ui.container.elasticsearch.enabled: true | ||
|
||
xpack.encryptedSavedObjects.encryptionKey: "12345678901234567890123456789012" | ||
xpack.monitoring.ui.container.elasticsearch.enabled: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mdelapenya feel free to modify the original config in the elastic-package tool.
/test |
Thanks for adding this. I tried it locally and built a test on top of that and seems to work well for my use case |
The error about missing GOPATH may also come from is there an option to print GOPATH and GOROOT? |
@mtojek it's possible to reproduce it locally from this PR too: $ TAGS="fleet_mode_agent && centos && install" TIMEOUT_FACTOR=3 LOG_LEVEL=TRACE DEVELOPER_MODE=true ELASTIC_APM_ACTIVE=false PROVIDER=elastic-package make -C e2e/_suites/fleet functional-test I also tried bumping elastic-package to v0.22.0 with same results |
Is there an option to extract the elastic-package invocation from there? Might be easier to test. EDIT: I managed to reproduce it, investigating:
EDIT2: I can see these problems, am I missing any additional auth?
|
Ok, so the problem is with shell executor in e2e-testing. I sneaked small change into the
and it fails with different error:
|
Mmm you are right. I think I have the fix for it, as we are overriding the entire ENV for cmd.Exec instead of appending! Good catch! |
Instead of replacing it, we want to append!
Merging, as the test error comes from the windows issue with fleet |
@nchaulet feel free to start building on top! 🚀 |
* chore: match elastic-package's kibana config * chore: bring back kibana's configuration file This will enable having multiple config files per test suite, using the profile abstraction: one dir per config with the profile name * chore: rename configurations to default It will represent the default profile * chore: make kibana profile configurable Default profile will be 'default' * feat: support bootstrapping the stack with a new kibana config The bootstrap method is called before the test suite (only once) AND before each test scenario, as it has been defined as a Background clause. If an scenario wants to configure a new config file for Kibana, a new profile file with the new kibana config must be created at the compose level, using the ProfileName as directory name. * feat: create an on-the-fly elastic-package's profile from compose * chore: override default kibana config for elastic-package * fix: remove unused code * docs: document kibana config and profiles * chore: add a profile for preconfgured-policies * elas * chore: add placeholder for preconfigured policies * chore: support passing custom kibana ref to elastic-package * fix: honour current env Instead of replacing it, we want to append! * chore: unit test that we are not overriding the env (cherry picked from commit a207500)
* chore: match elastic-package's kibana config * chore: bring back kibana's configuration file This will enable having multiple config files per test suite, using the profile abstraction: one dir per config with the profile name * chore: rename configurations to default It will represent the default profile * chore: make kibana profile configurable Default profile will be 'default' * feat: support bootstrapping the stack with a new kibana config The bootstrap method is called before the test suite (only once) AND before each test scenario, as it has been defined as a Background clause. If an scenario wants to configure a new config file for Kibana, a new profile file with the new kibana config must be created at the compose level, using the ProfileName as directory name. * feat: create an on-the-fly elastic-package's profile from compose * chore: override default kibana config for elastic-package * fix: remove unused code * docs: document kibana config and profiles * chore: add a profile for preconfgured-policies * elas * chore: add placeholder for preconfigured policies * chore: support passing custom kibana ref to elastic-package * fix: honour current env Instead of replacing it, we want to append! * chore: unit test that we are not overriding the env (cherry picked from commit a207500)
* chore: match elastic-package's kibana config * chore: bring back kibana's configuration file This will enable having multiple config files per test suite, using the profile abstraction: one dir per config with the profile name * chore: rename configurations to default It will represent the default profile * chore: make kibana profile configurable Default profile will be 'default' * feat: support bootstrapping the stack with a new kibana config The bootstrap method is called before the test suite (only once) AND before each test scenario, as it has been defined as a Background clause. If an scenario wants to configure a new config file for Kibana, a new profile file with the new kibana config must be created at the compose level, using the ProfileName as directory name. * feat: create an on-the-fly elastic-package's profile from compose * chore: override default kibana config for elastic-package * fix: remove unused code * docs: document kibana config and profiles * chore: add a profile for preconfgured-policies * elas * chore: add placeholder for preconfigured policies * chore: support passing custom kibana ref to elastic-package * fix: honour current env Instead of replacing it, we want to append! * chore: unit test that we are not overriding the env (cherry picked from commit a207500)
* chore: match elastic-package's kibana config * chore: bring back kibana's configuration file This will enable having multiple config files per test suite, using the profile abstraction: one dir per config with the profile name * chore: rename configurations to default It will represent the default profile * chore: make kibana profile configurable Default profile will be 'default' * feat: support bootstrapping the stack with a new kibana config The bootstrap method is called before the test suite (only once) AND before each test scenario, as it has been defined as a Background clause. If an scenario wants to configure a new config file for Kibana, a new profile file with the new kibana config must be created at the compose level, using the ProfileName as directory name. * feat: create an on-the-fly elastic-package's profile from compose * chore: override default kibana config for elastic-package * fix: remove unused code * docs: document kibana config and profiles * chore: add a profile for preconfgured-policies * elas * chore: add placeholder for preconfigured policies * chore: support passing custom kibana ref to elastic-package * fix: honour current env Instead of replacing it, we want to append! * chore: unit test that we are not overriding the env (cherry picked from commit a207500) Co-authored-by: Manuel de la Peña <[email protected]>
* chore: match elastic-package's kibana config * chore: bring back kibana's configuration file This will enable having multiple config files per test suite, using the profile abstraction: one dir per config with the profile name * chore: rename configurations to default It will represent the default profile * chore: make kibana profile configurable Default profile will be 'default' * feat: support bootstrapping the stack with a new kibana config The bootstrap method is called before the test suite (only once) AND before each test scenario, as it has been defined as a Background clause. If an scenario wants to configure a new config file for Kibana, a new profile file with the new kibana config must be created at the compose level, using the ProfileName as directory name. * feat: create an on-the-fly elastic-package's profile from compose * chore: override default kibana config for elastic-package * fix: remove unused code * docs: document kibana config and profiles * chore: add a profile for preconfgured-policies * elas * chore: add placeholder for preconfigured policies * chore: support passing custom kibana ref to elastic-package * fix: honour current env Instead of replacing it, we want to append! * chore: unit test that we are not overriding the env (cherry picked from commit a207500) Co-authored-by: Manuel de la Peña <[email protected]>
* chore: match elastic-package's kibana config * chore: bring back kibana's configuration file This will enable having multiple config files per test suite, using the profile abstraction: one dir per config with the profile name * chore: rename configurations to default It will represent the default profile * chore: make kibana profile configurable Default profile will be 'default' * feat: support bootstrapping the stack with a new kibana config The bootstrap method is called before the test suite (only once) AND before each test scenario, as it has been defined as a Background clause. If an scenario wants to configure a new config file for Kibana, a new profile file with the new kibana config must be created at the compose level, using the ProfileName as directory name. * feat: create an on-the-fly elastic-package's profile from compose * chore: override default kibana config for elastic-package * fix: remove unused code * docs: document kibana config and profiles * chore: add a profile for preconfgured-policies * elas * chore: add placeholder for preconfigured policies * chore: support passing custom kibana ref to elastic-package * fix: honour current env Instead of replacing it, we want to append! * chore: unit test that we are not overriding the env (cherry picked from commit a207500) Co-authored-by: Manuel de la Peña <[email protected]>
What does this PR do?
This PRs does a few important things:
default
, representing the name of the kibana profile to be useddefault
. It will copy there the contents of the profile's kibana.config.yml. Finally it will run the elastic-package tool with the new profileWhy is it important?
It will allow running different scenarios with different Kibana configs.
Checklist
make unit-test
), and they are passing locallymake notice
in the proper directory)Author's Checklist
How to test this PR locally
Related issues