metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Allen <n...@nickallen.org>
Subject Re: [DISCUSS] PCAP data for testing and development
Date Wed, 19 Sep 2018 12:22:25 GMT
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.





On Wed, Sep 19, 2018 at 8:12 AM Simon Elliston Ball <
simon@simonellistonball.com> wrote:

> 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
> through the pcap topology.
>
> Maybe we should have a method that instead of doing it continuously, has a
> 'do a loop and stop' version to load this data to keep the cpu weight down
> and provide data for testing UI functionality around PCAP.
>
> Simon
>
> On Wed, 19 Sep 2018 at 12:56, Tibor Meller <tibor.meller@gmail.com> wrote:
>
> > 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 would be
> > something similar to what we have in the Alert tab, which is to have some
> > pcap data available right after starting the VM.
> >
> > Do you guys think uploading pcap sample date as part of the
> > ansible provisioning step would be a good approach?
> > Or sensor stubs for pcap would be a better way?
> >
> > I would be curious about your thoughts!
> >
> > Thanks,
> > Tibor
> >
>
>
> --
> --
> simon elliston ball
> @sireb
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message