On 02.12.20 14:19, Dominik Csapak wrote: > On 12/2/20 2:11 PM, Thomas Lamprecht wrote: >> On 02.12.20 13:56, Dominik Csapak wrote: >>> instead of relying on the contentTypeField (which does not need to >>> exists, e.g. for iscsi), explicitely write it into the panel/icon >>> mapping and check that >> >> why not return it for iSCIS? > > > i don't understand what you mean? what should i return for iSCSI? > do you mean i should add a field to the iscsi panel? > (it has no content types to select, same as pbs/zfs over isci/etc.) > > >>> >>> better would be if we query the backend about storage capabilities, >>> but such an api call does not exist yet, so this should be ok for now >> >> that's not true, the content type is exactly how the backend provides that, >> that's why I used it. I'd like to avoid to further duplicating info all over >> the place. >> > > what i meant was the only 'real' way is to ask the backend > (be it once or every time) what capabilities the storage has. > > now we are simply querying what we hardcoded for each storage in > the frontend, my patch only adds a point where we save that specific > info (again), which is not ideal i know >
hmm, true, we only have that info for existing storage - had wrongly the content type split content view in mind... I'll rethink _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel