[Zeek-Dev] Zeek Supervisor Command-Line Client

[Vlad Grigorescu]

I'm still fuzzy on the Supervisor framework, as we're still in the process
of upgrading systems to the point of supporting the new C++ requirements.

As a concrete example, what does a cluster upgrade look like? Today, that
means install the new version on the manager, and then do `zeekctl deploy`,
which copies the files to the nodes and restarts the cluster. All of that
is done without Broker.

What does that look like with zeekcl + Broker? Let's say I install the new
version on the manager. If I then tell zeekcl to destroy the running
instance, will that work, or will the newer zeekcl be incompatible with the
Broker version of the running Zeek?

Reading the script linked in [2], I notice that zeekcl would not support
copying files from one node to another? Other features that would be
missing that we routinely use are `zeekctl print` and `zeekctl exec`. I'm
assuming `zeekcl` would be running in some uber-bare mode if it's written
in Zeek?

  --Vlad

On Thu, Jun 18, 2020 at 2:15 AM Jon Siwek <jsiwek at corelight.com> wrote:

> Don't recall any basic "project infrastructure" discussions happening
> yet for the upcoming replacement/alternative for ZeekControl that we
> want to introduce in Zeek 3.2 (roadmap/design links found at [1]), so
> here's starting questions.
>
> # What to Name It ?
>
> Suggestion: `zeekcl`, Zeek (Command-Line) CLlient.
>
> Open to ideas, but will use `zeekcl` below.
>
> # What Programming Language ?
>
> `zeekcl` has different/narrower scope than ZeekControl.  It's more
> clearly a "client" with sole job of handling requests/responses via
> Broker without many (any?) system-level operations/integrations.
> Meaning there may be less of an approachability/convenience gap
> between C++ versus Python with `zeekcl` than there was with
> ZeekControl.
>
> Also nice if `zeekcl` doesn't require more dependencies beyond what
> `zeek` needs since they're expected to be used together.
>
> Is use of Python still desirable for other reasons?  Otherwise, I lean
> towards `zeekcl` being C++.
>
> For reference/sanity-check in terms of what people expect `zeekcl` to
> be: in my testing of the SupervisorControl framework [2], I had a
> sloppy Zeek script implementing the full "client side" (essentially
> the majority of what `zeekcl` will do) in ~100 LOC.  Most operations
> are that simple: send request and display response.
>
> That does mean the third option to consider besides either Python or
> C++ is Zeek's scripting language (e.g. `ctl.zeek`), but I don't
> suggest that since (1) using a full `zeek` process is way more than we
> need and (2) the command-line interface is awkward (`zeek ctl
> Supervisor::cmd="status"` versus `zeekcl status`)
>
> # Where's the Source Code Live ?
>
> Past experiences with ZeekControl being in a separate repo than Zeek
> are negative in terms of CI/testing: changes in Zeek have broken
> ZeekControl, but go uncaught for a while since it is tested
> independently.
>
> Since common use/maintenance will involve both `zeek` and `zeekcl`,
> and also don't expect the later to accrue large amounts of code
> deserving of a separate project, I plan to have `zeekcl` code/tests
> live inside the main Zeek repo.
>
> - Jon
>
> [1] https://github.com/zeek/zeek/issues/582
> [2]
> https://github.com/zeek/zeek/blob/689a242836092fba7818ba24724b74a7a7902e48/scripts/base/frameworks/supervisor/control.zeek
> _______________________________________________
> Zeek-Dev mailing list
> Zeek-Dev at zeek.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20200618/5cc1271c/attachment.html