Add a step to exhaustive tests for observabilitySRE accetpance testing #17623
Conversation
This commit shows the proposed pattern for adding acceptance testing for the observability SRE image. This will run when exhaustive tests run. A new gradle task will hook in to rspec similar to how it is done for the smoke tests. The main difference is that instead of building a container, the latest is pulled from the container registry and run on a fips configured host VM.
| "instanceType": "m6i.xlarge", | ||
| "diskSizeGb": 60, | ||
| "instanceMaxAge": 1440, | ||
| "imagePrefix": "logstash-ubuntu-2204-fips" |
There was a problem hiding this comment.
This is currently blocked on some failing CI. The PR to build the image has been merged https://github.com/elastic/ingest-dev/issues/5469 though.
x-pack/build.gradle
Outdated
| description = "Run ObservabilitySRE acceptance tests" | ||
| // Need to have set up the ruby environment for rspec even through we are running in container | ||
| dependsOn(":bootstrap", ":logstash-core:assemble", ":installDevelopmentGems") | ||
| // TODO: hook in to rspec |
There was a problem hiding this comment.
I've proved out that on a fips host we can run these tasks. This will give us a consistent java/jruby env for which we can do the standard gradle/rake/rspec control flow.
For the next step in this PR i will be adding in some rspec that shows a pattern for doing container orchestration. At this point i'm thinking that will look like shelling out to docker-compose in rspec.
| ports: | ||
| - "9200:9200" | ||
| volumes: | ||
| - ./elasticsearch/config/${ELASTICSEARCH_CONFIG:-elasticsearch-fips.yml}:/usr/share/elasticsearch/config/elasticsearch.yml |
There was a problem hiding this comment.
This is how I will be swapping in different configurations of elasticsearch etc
| @@ -0,0 +1,14 @@ | |||
| # Elasticsearch settings | |||
| discovery.type: single-node | |||
There was a problem hiding this comment.
I will probably move toward file based ES config for smoke test as well, currently its done mainly in docker compose manifest
|
Still very much WIP. I have some cleanup and bugs to track down. Just wanted to get the structure out there breaking down responsibility between gradle/rspec etc and float the idea of changing configuration of components via interpolation in the docker compose file. |
donoghuc
force-pushed
the
fedramp-high-acceptance-tests
branch
2 times, most recently
from
569bedc to
94869d9
Compare
…tests This commit shows the rough structure for how I am planning on handling docker compose networks for acceptance tests. The main idea is to use interpolation in the docker compose file to point to different configuration files for filebeat/logstash/elasticsearch. This is mainly due to the nature of these tests showing behavior when the system is and is not configured properly for FIPS. The breakdown in responsibility is: 1. Gradle handles cert generation (similar to smoke test, this avoids checking in PKI) 2. Rspec handles stopping/starting docker compose and managing environment vars for intperolation in docker compose manifests (different from smoke tests where a single static docker compose is started in gradle) 3. Rspec handles deciding when containers are ready and querying state about data flowing through the system 4. Gradle cleans up certs THis is just a rough sketch, there are still bugs to be worked out but before i get too far in to it I want to get the idea out there.
donoghuc
force-pushed
the
fedramp-high-acceptance-tests
branch
from
94869d9 to
6c53570
Compare
|
I've got this all working locally. Specifically the rspec tests will now test that data goes from LS to ES with gradle generating certs and rspec managing container startup/teardown. We are still waiting on unblocking generation of a fips enabled test runner, but I'm happy with the patterns established here breaking down the responsibility between gradle/rspec and docker-compose. |
This commit adds a test to show that data will not flow from LS to ES when weak non fips config is used.
This will be handled separately in a separate PR, but taking this commit for now on this branch.
The latest ES images do not require this workaround.
|
💚 Build Succeeded
History
|
Release notes
[rn:skip]
What does this PR do?
This commit shows the proposed pattern for adding acceptance testing for the observability SRE image. This will run when exhaustive tests run. A new gradle task will hook in to rspec similar to how it is done for the smoke tests. The main difference is that instead of building a container, the latest is pulled from the container registry and run on a fips configured host VM.
Why is it important/What is the impact to the user?
NA
Checklist
Related issues