[pve-devel] [RFC PATCH guest-common 1/1] add profiles section config plugin

[Dominik Csapak]

On 11/6/23 11:12, Fiona Ebner wrote:
> 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, yes and no,

in a section config, we always have a global 'propertyList'
and a per type 'options' list (which only references the propertylist)

when using the 'create/updateSchema' calls, *all* options from the propertylist
will be included (incl. the type) so the id is always there

in the api calls, we then use this id, to modify the config
but it isn't actually contained in the 'options' of any type
and since we extract it from the parameters, it does not actually
land in the config part

(ofc this is a bit error-prone, and forgetting to extract it would
lead to the situation you describe)

> 
> E.g.
> 
> root at pve8a1 ~ # pvesm set pbsenc --storage foobar

this behaves like i mentioned above

> root at pve8a1 ~ # pvesm add dir foo --storage bar --path /var/lib/vz

i think this simply sets the 'storage' parameter twice, where the second
one is just overwritten by the first (i.e. you can always give any parameter
multiple times, but in this case the first one overwrites the later ones,
in contrast to when the parameter is not positional)

> root at pve8a1 ~ # grep bar /etc/pve/storage.cfg
> 1 root at pve8a1 ~ #
> 
> [0]: https://lists.proxmox.com/pipermail/pve-devel/2022-November/054714.html