Shane,
Can you elaborate on the testing model you're proposing? I looked through
the overview and some of the documentation. As far as I can tell, this
would effectively be and e2e test for the UI *only*, so we would be missing
testing the actual integration points with the REST API or any other
Thank you, Simon. The diagrams help a lot
19.09.2018, 21:27, "Simon Elliston Ball" :
> To clarify some of this I've put some documentation into
> https://github.com/apache/metron/pull/1203 under METRON-1755 (
> https://issues.apache.org/jira/browse/METRON-1755). Hopefully the diagrams
> there
To clarify some of this I've put some documentation into
https://github.com/apache/metron/pull/1203 under METRON-1755 (
https://issues.apache.org/jira/browse/METRON-1755). Hopefully the diagrams
there should make it clearer.
Simon
On Tue, 18 Sep 2018 at 14:17, Simon Elliston Ball <
I think what you have outlined above is a good initial stab at the feature.
Manual install of spark is not a big deal. Configuring via command line while
we mature this feature is ok as well. Doesn't look like configuration steps
are too hard. I think you should merge.
James
19.09.2018,
I would like to open a discussion to get the Batch Profiler feature branch
merged into master as part of METRON-1699 [1] Create Batch Profiler. All
of the work that I had in mind for our first draft of the Batch Profiler
has been completed. Please take a look through what I have and let me know
This article comparing the two is not favorable for Cypress. Are any of these
concerns relevant to us? If not, then I think Cypress is fine
https://hackernoon.com/cypress-io-vs-protractor-e2e-testing-battle-d124ece91dc7
I think another reason why we removed it was that it was being flagged by
antivirus tools. I am not sure that loop and stop would do anything because
the resources would still be taken up by idle topologies and idle sensors. I
think when we switch to containers and don't have to eat the
I would just be worried about resource constraints on the VM.
But Simon's idea of 'do a loop and stop' might be a good solution. We
could probably orchestrate that with Ansible tags actually. If you pass
the tag, it will 'do a loop and stop', but by default it keeps the current
behavior.
Isn't this what the pcap_replay role is for? We should be able to install
that role on full-dev and get the example.pcap file we currently ship to
replay and capture. It's not on by default in full dev because it's heavy
for most use cases, but should make it easy to load some sample pcap data
Hi all,
I would like to start a discussion on the possible ways to provide PCAP
data for the full dev.
The full dev VM after a rebuild contains no PCAP data. Currently,
I'm uploading binaries manually. This makes development slower and testing
problematic as well. I think a more desired outcome
Hello everyone,
Currently, we use Protractor to run our UI "end-to-end" tests. However,
there are a handful of major advantages we can gain from switching to
Cypress: https://www.cypress.io/features/.
- As with most Selenium-based e2e testing frameworks, Protractor suffers
from test
11 matches
Mail list logo
