On Tue, Jun 30, 2020 at 6:35 AM Seth Hall <s...@corelight.com> wrote:
> I'm really starting to think that the business logic for > correctly starting and stopping a cluster should be fully implemented in > the supervisor script. The zeekc tool could then just be a dumb tool > that says to start and stop and doesn't end up causing us to spread our > logic around to other tooling. Maybe the important observation is that the logic can be performed anywhere that has access to the Zeek-Supervisor process. * The Supervisor process itself would be able to perform the logic via direct BIF access. * External processes, like zeekc, have access to a Zeek-event interface to indirectly access those same BIFs, so they can also execute equivalent logic (either via multiple events, or a single "convenience" event that implements a sequence of BIF calls on remote) When we bring multi-hosting into the mix, it's still a similar situation, just with beefed up logic for orchestrating node-type-specific steps across many peers: anyone with access to the Zeek-event interface could implement this logic. You could pick zeekc to orchestrate, or you could pick a single Zeek-Supervisor process to orchestrate between other Supervisors, or you could pick a regular Zeek process, or you could write a Python script just using Broker Python bindings, etc. So where we put the logic at this point may not be important. If we can find a single-best-place for the logic to live, that's great, but if there's utility for others to have their own independent-yet-equivalent logic, I don't see a problem with that. - Jon _______________________________________________ Zeek-Dev mailing list Zeek-Dev@zeek.org http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev