Am 06.11.23 um 11:12 schrieb Fiona Ebner:
> Am 06.11.23 um 10:34 schrieb Dominik Csapak:
>> On 11/6/23 10:22, Fiona Ebner wrote:
>>> Am 03.11.23 um 12:53 schrieb Dominik Csapak:
>>>> +my $defaultData = {
>>>> + propertyList => {
>>>> + type => { description => 'Profile type.' },
>>>> + id => {
>>>> + type => 'string',
>>>> + description => "The ID of the profile.",
>>>> + format => 'pve-configid',
>>>> + },
>>>
>>> The ID is usually not a property AFAIK. Doesn't this lead to duplication
>>> when writing the section config, i.e.
>>>
>>> type: <ID>
>>> id <ID>
>>>
>>> ? Do we gain anything by having it be a property?
>>
>> mhm? the id has to be part of the properties, otherwise
>> the generated api with 'createSchema' etc. would not include it.
>>
>> (it isn't always named id, e.g. in the storage plugins
>> it's 'storage')
>>
>
> I was just reminded of [0], where it could lead to that situation. Would
> need to check if that patch still applies, because since then
> Jobs/RealmSync.pm has been added.
>
> But somebody needs to filter the 'storage' property, right? Isn't that
> property actually superfluous?
>
Well, it seems to be needed by the current storage config API
implementation. For the backup job API, it's no issue if no 'id'
property is declared explicitly in the config schema.
> E.g.
>
> root@pve8a1 ~ # pvesm set pbsenc --storage foobar
> root@pve8a1 ~ # pvesm add dir foo --storage bar --path /var/lib/vz
> root@pve8a1 ~ # grep bar /etc/pve/storage.cfg
> 1 root@pve8a1 ~ #
>
> [0]: https://lists.proxmox.com/pipermail/pve-devel/2022-November/054714.html
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
