[pbs-devel] [PATCH proxmox-backup] tape: fix 'eject-before-unload' api type

[Thomas Lamprecht]

Am 14/12/2023 um 08:52 schrieb Dominik Csapak:
> mhmm i modeled it after the 'tuning' options of the datastore.
> maybe it was named badly, and the 'options' should be replaced by 
> 'quirks' (as in, changer quirks that only some people need, like
> the datastore tuning options)

'quirks' would be already a lot better than the overly generic 'options',
but IMO the changer scope of possible functionality and how, and in which
context, they can be used is quite a bit smaller than the scope of a
datastore, which can be involved in many different actions/jobs.  For
tuning's we also already knew a few specific things that could be done, so
there it was IMO indeed slightly better to go for a property string.

And sure, this here isn't a total clear-cut where having it in a property
string is just plain wrong, it definitively isn't just wrong, but IMO, as
long as we do not have more options of this category for changers it's too
hard to future-proof this now already, and in that case the simpler way (for
user and API maintenance) is having this an explicit separate option, not a
nested one.

> but if you both want a more straight forward option directly in
> the changer config, then it's also fine with me (i just
> did not want to pollute the changer config with rather
> specific quirk workarounds, and I doubt this is
> the last of them, even though we don't see such things often)

Yeah, I also think that there will be some, but I'd find it odd if there are
many. And if many have to be added in a short period it's probably due to
some standard change (e.g., LTO 10 doing/requiring very new weird stuff),
and in that case it might be better to have that set of new options in a
option group that is specific to that change, for the previous example that
could be grouped to something like `lto: [<version>=]10[,<other-options>]` 

And whatever it will be, once it isn't a pipe dream prediction anymore, but
became actual reality, we can way better choose; and if it then means moving
those to a "quirks" property to avoid bloat/whatever, then you were right
and we can change it to that (with some, but not all to big, backward compat
work). 
But for this option I don't see the hard evidence that just would suggest
now that a relative generic 'quirks' will be the best fit.

> just tell me if i should rename it to something else (like quirks)
> or if i should put it directly in the changer config, and i'll send
> the patches for it + docs update

I'd favor having this moved out directly in the change config for now.