Re: [DISCUSS] e2e test infrastructure

We will also need an ES and Metron REST container for the e2e tests, but yeah you get the idea. I think having the tests be responsible for setup will work. Maybe the next step is to build a simple example and let everyone try it out. If we don't like it, we can throw it away. On Wed, Nov 29,

Re: [DISCUSS] e2e test infrastructure

So we will just have a : ZK container Kafka Container HDFS Container and not deploy any metron stuff to them in the docker setup, the test itself will deploy what it needs and cleanup? On November 29, 2017 at 11:53:46, Ryan Merriman (merrim...@gmail.com) wrote: “I would feel better using

Re: [DISCUSS] e2e test infrastructure

“I would feel better using docker if each docker container only had the base services, and did not require a separate but parallel deployment path to ambari” This exactly how it works. There is a container for each base service, just like we now have an in-memory component for each base

Re: [DISCUSS] e2e test infrastructure

Honestly, I'm ok with either the in-memory component approach or the docker approach as long as: - It runs in travis - The infrastructure components are spun up in a way that isolates their classpath - The UI e2e test and the integration tests both use the same infrastructure I

Re: [DISCUSS] e2e test infrastructure

Mike, I think we are in agreement: any solution involving in-memory components would have them running in separate processes vs. a single process like they do now. > On Nov 29, 2017, at 9:14 AM, Michael Miklavcic > wrote: > > I understood the item on "in-memory

Re: [DISCUSS] e2e test infrastructure

So the issue with metron-docker is that it is all custom setup for metron components, and understanding how to maintain it when you make changes to the system is difficult for the developers. This is a particular issue to me, because I would have to re-write a big chunk of it to accommodate 777.

Re: [DISCUSS] e2e test infrastructure

I understood the item on "in-memory components" to be similar to what we're currently doing in the integration tests, which we cannot and should not do. They are spun up in a single jvm process which causes major problems with classpath isolation. My main point here is to be sure each component is

Re: [DISCUSS] e2e test infrastructure

Thanks for the feedback so far everyone. All good points. Otto, if we did decide to go down the Docker route, we could use /master/metron-contrib/metron-docker as a starting point. The reason I initially create that module was to support Management UI testing because full dev was unusable for

Re: [DISCUSS] e2e test infrastructure

I'd also be strongly in favor of having 1 approach to running our e2e and integration tests. On Wed, Nov 29, 2017 at 5:59 AM, Justin Leet wrote: > As an additional consideration, it would be really nice to get our current > set of integration tests to be able to be run on

Re: [DISCUSS] e2e test infrastructure

As an additional consideration, it would be really nice to get our current set of integration tests to be able to be run on this infrastructure as well. Or at least able to be converted in a known manner. Eventually, we could probably split out the integration tests from the unit tests entirely.

Re: [DISCUSS] e2e test infrastructure

As long as there is not a large chuck of custom deployment that has to be maintained docker sounds ideal. I would like to understand what it would take to create the docker e2e env. On November 28, 2017 at 17:27:13, Ryan Merriman (merrim...@gmail.com) wrote: Currently the e2e tests for our

[DISCUSS] e2e test infrastructure

Currently the e2e tests for our Alerts UI depends on full dev being up and running. This is not a good long term solution because it forces a contributor/reviewer to run the tests manually with full dev running. It would be better if the backend services could be made available to the e2e tests