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 <jsi...@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@zeek.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >
_______________________________________________ Zeek-Dev mailing list Zeek-Dev@zeek.org http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
