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 < si...@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.mel...@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 >
