On Tue, Jun 30, 2020 at 14:29 -0700, Jon Siwek wrote:
> Maybe the important observation is that the logic can be performed
> anywhere that has access to the Zeek-Supervisor process.
Agree.
> So where we put the logic at this point may not be important. If we
> can find a single-best-place for
On Tue, Jun 30, 2020 at 6:35 AM Seth Hall 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
On Tue, Jun 30, 2020 at 09:35 -0400, I wrote:
> I think that the script we ship with zeek that effectively implements the
> supervisor behavior should understand the business logic of shutting down a
> cluster in the correct order.
How would that then work across multiple systems?
Robin
--
Sorry for chiming in late on this...
On 19 Jun 2020, at 14:46, Jon Siwek wrote:
> Ack, got it and agree that the distinction is likely helpful: the
> supervisor node implements the low-level "dirty work" of stopping
> processes and can ensure shutdown of its entire process tree if it
> really
On Fri, Jun 19, 2020 at 1:38 AM Robin Sommer wrote:
> think we also want their state controllable from the client as well,
> so that one can have an orderly shutdown of a multi-system cluster
> without loss of data (e.g., one probably wants to shutdown workers
> first to collect remaining log
On Thu, Jun 18, 2020 at 13:00 -0700, Jon Siwek wrote:
> > For (1), the above applies: we'll rely on standard sysadmin processes
> > for updating. That means you'd use "zeekcl" to shutdown the cluster
> > processes, then run "yum update" (or whatever), then use "zeekcl"
> > again to start
>> Suggestion: `zeekcl`, Zeek (Command-Line) CLlient.
>
> "zeekcl" is very close to "zeekctl", which could lead to confusion.
> "zcl" maybe?
>
>> Is use of Python still desirable for other reasons? Otherwise, I
>> lean
>> towards `zeekcl` being C++.
>
> No particular preference from my side, I
On Thu, Jun 18, 2020 at 7:45 AM Vlad Grigorescu wrote:
> My main concern was Broker version incompatibilities between the
> newly-installed zcl, and the running cluster, which I think would be
> addressed by that (i.e. to stop a cluster, you stop the supervisor service on
> the manager, and
On Thu, Jun 18, 2020 at 12:11 AM Robin Sommer wrote:
> For (1), the above applies: we'll rely on standard sysadmin processes
> for updating. That means you'd use "zeekcl" to shutdown the cluster
> processes, then run "yum update" (or whatever), then use "zeekcl"
> again to start things up again.
Thanks Robin, that helps.
On Thu, Jun 18, 2020 at 2:11 AM Robin Sommer wrote:
>
> There are two parts here: (1) deploying the Zeek installation itself,
> and (2) deploying any configuration changes (incl. new Zeek scripts).
>
> For (1), the above applies: we'll rely on standard sysadmin
On Thu, Jun 18, 2020 at 03:32 +, Vlad Grigorescu wrote:
> As a concrete example, what does a cluster upgrade look like?
The idea is to handle this more like other system services: you'll be
in charge of getting the new Zeek version onto all your systems
yourself, using whatever method you
> Suggestion: `zeekcl`, Zeek (Command-Line) CLlient.
"zeekcl" is very close to "zeekctl", which could lead to confusion.
"zcl" maybe?
> Is use of Python still desirable for other reasons? Otherwise, I lean
> towards `zeekcl` being C++.
No particular preference from my side, I can see either.
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
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
14 matches
Mail list logo
