From: Jakub Kicinski <kuba@kernel.org>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Breno Leitao <leitao@debian.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
sergey.senozhatsky@gmail.com, pmladek@suse.com, tj@kernel.org,
Dave Jones <davej@codemonkey.org.uk>,
"open list:NETWORKING DRIVERS" <netdev@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] netconsole: Append kernel version to message
Date: Wed, 5 Jul 2023 08:49:58 -0700 [thread overview]
Message-ID: <20230705084958.1c4854eb@kernel.org> (raw)
In-Reply-To: <20230705082604.7b104a48@hermes.local>
On Wed, 5 Jul 2023 08:26:04 -0700 Stephen Hemminger wrote:
> On Wed, 5 Jul 2023 02:18:03 -0700
> Breno Leitao <leitao@debian.org> wrote:
>
> > The uname is useful if the receiver side is looking (grepping) for
> > specific messages (warnings, oops, etc) affecting specific kernel
> > versions. If the uname is not available, the receiver needs to read boot
> > message and keep a map for source IP to kernel version. This is far from
> > ideal at a hyperscale level.
>
> At hyperscale you need a real collector (not just netcat) that can consult
> the VM database to based on IP and record the meta data there. If you allow
> random updates and versions, things get out of control real fast and this
> won't really help much
VM world is simpler because the orchestrator knows exactly what it's
launching each time. Bare metal is more complicated, especially
with modern automation designs where the DBs may contain _intended_
state, and local host agent performs actions to bring the machine
into the intended state.
Not to mention that there may be multiple kernels at play (provisioning
flow, bootloader / EFI, prod, kdump etc.)
As a kernel dev I do like the 100% certainty as to which kernel version
was running at the time of the problem.
next prev parent reply other threads:[~2023-07-05 15:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-03 15:41 [PATCH] netconsole: Append kernel version to message leitao
2023-07-03 16:46 ` Andrew Lunn
2023-07-04 15:53 ` Breno Leitao
2023-07-03 18:34 ` Stephen Hemminger
2023-07-04 15:15 ` Breno Leitao
2023-07-04 15:58 ` Stephen Hemminger
2023-07-05 9:18 ` Breno Leitao
2023-07-05 15:26 ` Stephen Hemminger
2023-07-05 15:49 ` Jakub Kicinski [this message]
2023-07-03 19:44 ` Jakub Kicinski
2023-07-04 15:47 ` Breno Leitao
2023-07-05 15:56 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230705084958.1c4854eb@kernel.org \
--to=kuba@kernel.org \
--cc=davej@codemonkey.org.uk \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pmladek@suse.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=stephen@networkplumber.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).