public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Leo Nunner <l.nunner@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server] feature #3937: config: store user in meta property
Date: Wed, 15 Feb 2023 10:05:08 +0100	[thread overview]
Message-ID: <a4063e1b-4e4a-1561-bc77-20e1d1dbf0d2@proxmox.com> (raw)
In-Reply-To: <47190234-9400-4060-0a92-d774eda7c436@proxmox.com>

On 2023-02-14 10:41, Thomas Lamprecht wrote:
> On 13/02/2023 11:24, Leo Nunner wrote:
>> Adds a field to the "meta" config property which stores the user who
>> created the VM.
> Should also get this finally added to CTs, I know it's a bit unfair to
> add the burden to this patch series, but otherwise we might never add
> it.. 
>
>> Signed-off-by: Leo Nunner <l.nunner@proxmox.com>
>> ---
>>  PVE/QemuServer.pm | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
>> index a0e16dc..28ed8e7 100644
>> --- a/PVE/QemuServer.pm
>> +++ b/PVE/QemuServer.pm
>> @@ -281,6 +281,11 @@ my $meta_info_fmt = {
>>  	pattern => '\d+(\.\d+)+',
>>  	optional => 1,
>>      },
>> +    'user' => {
> It adds a bit of property length, but it might be good to follow the other
> properties and use a bit more self-explanatory 'creation-user' here?

Good idea, I'll change it accordingly.

> I mean, I don't hope that we add to much properties here, but in retrospect
> the property name "meta" might have been a bit to general, something like
> "creation-env" could have been a better choice - but as said, I still
> hope that we don't add to much there anyway.
>
> otoh, maybe this is even "to much" for such a thing, a dedicated audit log
> might be better in general? (I got that with some rough planning on our
> internal wiki) 

FWIW, I actually started working on the CT implementation already (after
Fiona pointed out that the report was requesting it for both VMs and
CTs). I read through the ideas for the auditing framework and it does
seem like it would be a much better fit there - but then again, the
property might make accountability a bit easier, since instead of
filtering logs (which could probably be quite some time in the past) one
just needs to read the meta property in the config file… Maybe both
would be good?





      reply	other threads:[~2023-02-15  9:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13 10:24 Leo Nunner
2023-02-14  9:41 ` Thomas Lamprecht
2023-02-15  9:05   ` Leo Nunner [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=a4063e1b-4e4a-1561-bc77-20e1d1dbf0d2@proxmox.com \
    --to=l.nunner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@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