public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
	Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] api: tape: don't allow overwriting of ids in changer/drive config
Date: Wed, 6 Mar 2024 10:24:59 +0100	[thread overview]
Message-ID: <12a85d4c-4d48-4d14-be2d-6199aa7e9474@proxmox.com> (raw)
In-Reply-To: <738ea02b-aacc-42da-9bc4-4165a5e0942c@proxmox.com>

Am 06/03/2024 um 10:09 schrieb Dominik Csapak:
> On 3/6/24 09:56, Thomas Lamprecht wrote:
>> Am 06/03/2024 um 09:47 schrieb Dominik Csapak:
>>> by checking the whole section config for an existing id, not only the
>>> ones of the given type.
>>>
>>> This prevents creation of a drive config with the same name as an
>>> existing changer and vice versa.
>>
>> Ok, but why is that bad? Just confusion potential, does something
>> break as we only use the ID without the section-key later on, ...?
>>
>> Describing the effects/background, even if rather obvious, would
>> be still appreciated.
> 
> ah yes, sorry
> 
> first, it's really unexpected that creating a changer 'foo' deletes the existing drive 'foo'
> (or vice versa).
> 
> but it also breaks our assumptions a bit, for example:
> 
> i create a changer 'foo'
> then i create the drive 'foo' and select changer 'foo' as it's changer
> 
> this works, but afterwards i don't have the changer anymore in the config
> but the drive still references that
> 
> when i now select the changer 'foo' in the navigation, i'm
> greeted with the error:
> 
> `got unexpected type 'lto' for changer 'foo'`

Ok, yeah, disallowing this explicitly sounds sensible enough and
easier compared to fixing support for changer and drive having their
own ID namespace.

> 
> should i send a  v2 with an updated commit message?
> 

yes please, as going in the other direction (fully support this) is
an option it would be good to encode that we actively decided against
it (as that's to cheap to not do even if we never need to rethink
this again).




      reply	other threads:[~2024-03-06  9:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06  8:47 Dominik Csapak
2024-03-06  8:56 ` Thomas Lamprecht
2024-03-06  9:09   ` Dominik Csapak
2024-03-06  9:24     ` 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=12a85d4c-4d48-4d14-be2d-6199aa7e9474@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pbs-devel@lists.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