[pve-devel] [PATCH installer] tui: multiply the disk size back into bytes

[pve-devel] [PATCH installer] tui: multiply the disk size back into bytes

[Stefan Sterz]

previously the installer correctly divided the value when using them
for the `FloatEditView`, but forgot to multiply the value again when
retrieving it after editing. this commit fixes that

Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
---
tested this only locally and didn't build the installer completelly.
i am not sure if the installer handles this value correctly once it
is forwarded to the perl installer. if the perl installer expects
bytes here, it should work just fine, though.

 proxmox-tui-installer/src/views/mod.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/proxmox-tui-installer/src/views/mod.rs b/proxmox-tui-installer/src/views/mod.rs
index 94c3993..8503d82 100644
--- a/proxmox-tui-installer/src/views/mod.rs
+++ b/proxmox-tui-installer/src/views/mod.rs
@@ -234,7 +234,7 @@ impl DiskSizeEditView {
                 .flatten()
         })
         .flatten()
-        .map(|val| val as u64)
+        .map(|val| (val * 1024. * 1024. * 1024.) as u64)
     }
 }
 
-- 
2.39.2

Re: [pve-devel] [PATCH installer] tui: multiply the disk size back into bytes

[Thomas Lamprecht]

Am 21/06/2023 um 16:00 schrieb Stefan Sterz:
> previously the installer correctly divided the value when using them
> for the `FloatEditView`, but forgot to multiply the value again when
> retrieving it after editing. this commit fixes that
> 
> Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
> ---
> tested this only locally and didn't build the installer completelly.
> i am not sure if the installer handles this value correctly once it
> is forwarded to the perl installer. if the perl installer expects
> bytes here, it should work just fine, though.

no it doesn't it expects Gigabyte in floats, see:
https://git.proxmox.com/?p=pve-installer.git;a=commitdiff;h=9a2d64977f73cec225c407ff13765ef02e2ff9e9

Re: [pve-devel] [PATCH installer] tui: multiply the disk size back into bytes

[Stefan Sterz]

On 21.06.23 16:36, Thomas Lamprecht wrote:
> Am 21/06/2023 um 16:00 schrieb Stefan Sterz:
>> previously the installer correctly divided the value when using them
>> for the `FloatEditView`, but forgot to multiply the value again when
>> retrieving it after editing. this commit fixes that
>>
>> Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
>> ---
>> tested this only locally and didn't build the installer completelly.
>> i am not sure if the installer handles this value correctly once it
>> is forwarded to the perl installer. if the perl installer expects
>> bytes here, it should work just fine, though.
> 
> no it doesn't it expects Gigabyte in floats, see:
> https://git.proxmox.com/?p=pve-installer.git;a=commitdiff;h=9a2d64977f73cec225c407ff13765ef02e2ff9e9
> 

alright, thanks for that, i am not too familiar with this code base ^^'.
should we then model these sizes as `f64` instead?

i'd go ahead and prepare a patch with that, but it's a bit more churn so
i want to make sure that's the way to go.

Re: [pve-devel] [PATCH installer] tui: multiply the disk size back into bytes

[Thomas Lamprecht]

Am 22/06/2023 um 08:56 schrieb Stefan Sterz:
> On 21.06.23 16:36, Thomas Lamprecht wrote:
>> Am 21/06/2023 um 16:00 schrieb Stefan Sterz:
>>> previously the installer correctly divided the value when using them
>>> for the `FloatEditView`, but forgot to multiply the value again when
>>> retrieving it after editing. this commit fixes that
>>>
>>> Signed-off-by: Stefan Sterz <s.sterz@proxmox.com>
>>> ---
>>> tested this only locally and didn't build the installer completelly.
>>> i am not sure if the installer handles this value correctly once it
>>> is forwarded to the perl installer. if the perl installer expects
>>> bytes here, it should work just fine, though.
>>
>> no it doesn't it expects Gigabyte in floats, see:
>> https://git.proxmox.com/?p=pve-installer.git;a=commitdiff;h=9a2d64977f73cec225c407ff13765ef02e2ff9e9
>>
> 
> alright, thanks for that, i am not too familiar with this code base ^^'.
> should we then model these sizes as `f64` instead?

tbh. I though Christoph already switched all of those over to f64.

> 
> i'd go ahead and prepare a patch with that, but it's a bit more churn so
> i want to make sure that's the way to go.

I mean, in the end we need to be able to get a float of GB, so either we
use here af f64 that ensures all of the code doing the actual installation
needs no change, and thus has no regression potential, or we switch the
installation config over to megabytes (which would be enough for all
practicable disk sizes, especially as we expose only two decimal places
anyway.