Add option to notify test service after agent policy is applied#229
Add option to notify test service after agent policy is applied#229andrewkroh merged 2 commits intoelastic:masterfrom
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
|
|
Failing build is fixed by #230. |
mtojek
left a comment
There was a problem hiding this comment.
An alternative would be to start the test service container after the policy is applied, but
this could affect tests where the agent connects to the service (e.g. a prometheus exporter)
since the test might expect the service to be ready at startup.
It looks like a classic "chicken and egg" problem. Most likely we'd have to ignore potential connectivity errors at the beginning. Maybe it's a better idea, but let's defer it at the moment.
Usually in such cases we depended on infinite stream of events (e.g. healthcheck calling curl :80/). I assume that you wouldn't like to follow this scheme, right?
This adds a config option, `service_notify_signal`, to the system test runner to
allow the test runner to notify the service via a signal (e.g. SIGHUP) after the
policy has been applied by the Agent.
This is useful when the test service is connecting to the listening agent or streaming data
to the agent.
It helps address two issues that I encountered.
1. While repeatedly testing the agent stays up with the old policy applied, but
before the new policy is applied and the old ES data cleared the test service would
connect and deliver data to the "old" agent/policy.
2. For UDP streams there is no reliable way to know that the agent is ready and listening.
An alternative would be to start the test service container after the policy is applied, but
this could affect tests where the agent connects to the service (e.g. a prometheus exporter)
since the test might expect the service to be ready at startup.
4346efe to
20759cc
Compare
That sounds interesting, could you elaborate a little more what you were thinking. Like making the test service wait on some condition to become true? The only option I can think of is to access the API in kibana to monitor where the agent policy is applied. |
|
The Apache integration is tested with the regular traffic generated by Docker healthcheck: https://github.com/elastic/integrations/blob/master/packages/apache/_dev/deploy/docker/Dockerfile#L5 . Maybe you can also adapt a similar logic (the healthcheck is a trigger). |
mtojek
left a comment
There was a problem hiding this comment.
I think this feature/configuration option is useful and we may also use it in other places. If there isn't any simpler solution, let's not block it.
Add system tests for the UDP and TCP inputs in the CheckPoint Firewall data stream. Depends on: elastic/elastic-package#229
This adds a config option,
service_notify_signal, to the system test runner toallow the test runner to notify the service via a signal (e.g. SIGHUP) after the
policy has been applied by the Agent.
This is useful when the test service is connecting to the listening agent or streaming data
to the agent.
It helps address two issues that I encountered.
before the new policy is applied and the old ES data cleared the test service would
connect and deliver data to the "old" agent/policy.
An alternative would be to start the test service container after the policy is applied, but
this could affect tests where the agent connects to the service (e.g. a prometheus exporter)
since the test might expect the service to be ready at startup.
Test Logs