public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Stefan Sterz <s.sterz@proxmox.com>,
	Fiona Ebner <f.ebner@proxmox.com>,
	Mira Limbeck <m.limbeck@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] report: filter comments in VM/CT configs
Date: Fri, 30 Dec 2022 15:34:58 +0100	[thread overview]
Message-ID: <573bf500-354c-3d74-c224-5251d5c4bbca@proxmox.com> (raw)
In-Reply-To: <e3a71252-2aca-0e89-a68c-cd98a5b05fb9@proxmox.com>

Am 28/12/2022 um 15:18 schrieb Stefan Sterz:
> maybe somewhat off-topic for the patch at hand, but it might be nice to
> modularize the pve report. so that `pvereport` gives you a default set
> of information, but you could also use `pvereport ha` to give you more
> information specifically about the state of the ha manager or `pvereport
> ceph` for information about ceph etc.
> 
> maybe paired with a verbose flag so that you could request more detailed
> info. e.g. `pvereport zfs` gives the zfs information currently in the
> report, but `pvereport zfs -v` could also include `arc_summary` and `cat
> /sys/module/zfs/parameters/zfs_arc_max` and other less often needed but
> sometimes useful information.
> 
> this might be handy especially in cases where you need information that
> spans several files/commands that aren't always needed. it might make
> the `pvereport` more useful in the forum too, where we currently can't
> use it at all because it discloses too much information.
> 
I'd rather keep it simple and not blow it up too much with a massive amount of
switches, lots of topics are very intertwined, e.g., ha issues often need most
information to have a full picture, i.e., it never hurts to have more
information. Also note that the forum is the community one and so IMO the wrong
place for any generic enterprise support report request, publicly readable for
all compared to the subscription contract and private enterprise support portal.

If, a generic (public) IP hashing might be sensible, and if that's done such
that it's still relatively easy to trace the different used one (i.e., a more
human readable/comparable hash than md5/SHA/...) it can be just always turned
on too.




      reply	other threads:[~2022-12-30 14:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-15 16:57 Mira Limbeck
2022-12-16  9:01 ` Stefan Sterz
2022-12-16 10:31 ` Thomas Lamprecht
2022-12-16 11:14   ` Mira Limbeck
2022-12-16 12:15 ` Fiona Ebner
2022-12-28 14:18   ` Stefan Sterz
2022-12-30 14:34     ` Thomas Lamprecht [this message]

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=573bf500-354c-3d74-c224-5251d5c4bbca@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=f.ebner@proxmox.com \
    --cc=m.limbeck@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=s.sterz@proxmox.com \
    /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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal