public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Severen Redwood via pve-devel <pve-devel@lists.proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: Severen Redwood <severen.redwood@sitehost.co.nz>,
	Thomas Lamprecht <t.lamprecht@proxmox.com>
Subject: Re: [pve-devel] [PATCH cluster v4 1/2] cluster files: add used_vmids.list
Date: Wed, 26 Mar 2025 16:51:23 +1300	[thread overview]
Message-ID: <mailman.191.1742961543.359.pve-devel@lists.proxmox.com> (raw)
In-Reply-To: <b8f26204-e6d2-40b6-8048-0f9883d65b4d@proxmox.com>

[-- Attachment #1: Type: message/rfc822, Size: 5074 bytes --]

From: Severen Redwood <severen.redwood@sitehost.co.nz>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: "Thomas Lamprecht" <t.lamprecht@proxmox.com>, "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH cluster v4 1/2] cluster files: add used_vmids.list
Date: Wed, 26 Mar 2025 16:51:23 +1300
Message-ID: <fd441572-6c7c-4b62-bdef-0d738ac699fb@sitehost.co.nz>

On 29/01/2025 03:57, Thomas Lamprecht wrote:
> Am 27.01.25 um 13:18 schrieb Fabian Grünbichler:
>>> Severen Redwood via pve-devel <pve-devel@lists.proxmox.com> hat am 08.11.2024 02:46 CET geschrieben:
>>
>>> Add `/etc/pve/used_vmids.list` to the list of cluster files, which will
>>> be used for recording previously used VM/CT IDs. This is required so
>>> that we can optionally ensure that such IDs are not suggested by the
>>> `/cluster/nextid` API endpoint.
>>
>> this is encroaching bikeshed-territory, but we don't currently use ".list" as an extension in /etc/pve (and I automatically have to think of APT repository files when seeing it ;)). I think a plain "used_vmids" or "used-vmids" would also work?
>>
>> maybe somebody else has an opinion or suggestion?
> 
> I agree, and I would prefer kebab-case in any way, i.e.: used-vmids

No problem, I've changed it to `/etc/pve/used-ids` now. Slightly more generic than `used-vmids` since there are also container IDs.

> Besides that it mostly depends on if we want to re-use a common file for other
> such specific use cases around VMIDs like per-{user,group,pool} reservations
> (or allow-lists) of VMID ranges.
> 
> One certainly does not need to implement that for landing this series, but
> might be worth use a slightly more structured format and generalized file
> name to allow easier extension in that direction without new files and
> only needing to look at a single file when allocating VMID.
> But this can also be adapted on applying, it should mostly affect parsing
> and serialization, and maybe those even not _that_ much.
I've not done this just yet since I'm not sure what sort of format you would prefer. Possibly some kind of section headers to separate out the different parts of the file? But maybe it's best to leave that for when the patches are applied.


[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

  reply	other threads:[~2025-03-26  3:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-08  1:44 [pve-devel] [PATCH SERIES v4] Add ability to prevent suggesting previously used VM/CT IDs Severen Redwood via pve-devel
2024-11-08  1:46 ` [pve-devel] [PATCH manager v4 1/2] close #4369: api: optionally only suggest unique IDs Severen Redwood via pve-devel
2025-01-27 12:16   ` Fabian Grünbichler
2025-03-26  3:50     ` Severen Redwood via pve-devel
     [not found] ` <20241108014620.73352-1-severen.redwood@sitehost.co.nz>
2024-11-08  1:46   ` [pve-devel] [PATCH manager v4 2/2] close #4369: ui: add datacenter option for unique VM/CT IDs Severen Redwood via pve-devel
2024-11-08  1:46   ` [pve-devel] [PATCH cluster v4 1/2] cluster files: add used_vmids.list Severen Redwood via pve-devel
2025-01-27 12:18     ` Fabian Grünbichler
2025-01-28 14:57       ` Thomas Lamprecht
2025-03-26  3:51         ` Severen Redwood via pve-devel [this message]
     [not found]         ` <fd441572-6c7c-4b62-bdef-0d738ac699fb@sitehost.co.nz>
2025-03-26  7:22           ` Thomas Lamprecht
2025-03-27 21:02             ` Severen Redwood via pve-devel
2024-11-08  1:46   ` [pve-devel] [PATCH cluster v4 2/2] datacenter config: add unique-next-id to schema Severen Redwood via pve-devel
2024-11-08  1:46   ` [pve-devel] [PATCH qemu-server v4] api: record VM ID as used after a virtual machine is destroyed Severen Redwood via pve-devel
2024-11-08  1:46   ` [pve-devel] [PATCH container v4] api: record CT ID as used after a container " Severen Redwood via pve-devel
2025-01-27 12:16     ` Fabian Grünbichler
2025-03-26  3:51       ` Severen Redwood via pve-devel
2024-12-03 21:43 ` [pve-devel] [PATCH SERIES v4] Add ability to prevent suggesting previously used VM/CT IDs Severen Redwood via pve-devel
     [not found] ` <d39f8d05-d5a6-48c9-996a-dca751f62ff3@sitehost.co.nz>
2025-01-19 22:01   ` Severen Redwood via pve-devel

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=mailman.191.1742961543.359.pve-devel@lists.proxmox.com \
    --to=pve-devel@lists.proxmox.com \
    --cc=severen.redwood@sitehost.co.nz \
    --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