apache / cloudstack-cloudmonkey

Apache Cloudstack Cloudmonkey
Apache License 2.0
92 stars 61 forks source link

add human readable output #94

Closed pdion891 closed 1 year ago

pdion891 commented 3 years ago

when displaying volume info, it would be great if we could see the size attribute in human readable form instead of scientific, example:

current output:

> list volumes type=DATADISK filter=size
count = 1
volume:
+-----------------+
|      SIZE       |
+-----------------+
| 5.36870912e+10  |
+-----------------+

new output:

> list volumes type=DATADISK filter=size
count = 1
volume:
+-----------------+
|      SIZE       |
+-----------------+
|      50 GB      |
+-----------------+

Maybe we could have a configuration humanformat=true in the config file too ?

rohityadavcloud commented 3 years ago

Good idea, I think it's sort of a regression - we shouldn't round of to the x.xeY format. This only happens for the text output, does not happy for the json output. The immediate fix we can attempt is to output the same number (as-is) than change the format cc @Pearl1594

rohityadavcloud commented 3 years ago

The linked PR fixes the formatting issue, however it doesn't do what @pdion891 has asked - PL please check if the PR is sufficient to close the ticket as ideally the human readable change should come from API key so the CLI shouldn't alter the response too much.

pdion891 commented 3 years ago

The #95 make reading better than before but I think it would be cleaner if we could get a more human interpreted version.

is such code could help ?

func convert(i int64) string {
    v := []string{"B", "KB", "MB", "GB", "TB", "PB", "EB"}
    l := 0
    for ; i > 1024; i = i / 1024 {
        l++
    }
    return fmt.Sprintf("%d %s", i, v[l])
}

This could work for any field that are size or memory, but cannot be use for all integer type because that would not make sense for cpu count as example.

rohityadavcloud commented 3 years ago

That looks good - but then the issue is on which int64 inputs (i.e. response keys) should we apply this logic? (probably anything with size in the substring? however it may fail if it's not storage related key)

pdion891 commented 3 years ago

int64 in that snippet can be changed.

Pearl1594 commented 3 years ago

It does look better with the approach you've mentioned @pdion891. However, this may not work for fields like cpunumber, cpuspeed, bits, count, etc - but it's worth exploring!

pdion891 commented 3 years ago

@Pearl1594 for sur this kind of output is only valid for Size type of attribute.

Would there be a way to know if an attribute name contain size and if it does the value would be process to have GB output style ?

borisstoyanov commented 1 year ago

@Pearl1594 are you still looking to work on this issue?

borisstoyanov commented 1 year ago

I don't think the fix should be in cmk, cmk is a simple tool that displays whatever the api response has. If anywhere the fix should be in the API response. There was a PR back in the days for 'human readable' output that went through most parts in cloudstack and made all these size/volumes into more sensible units. I think we should close this

pdion891 commented 1 year ago

I agree, if cloudstack api output can be in human readable format, this feature request in cmk is not valid anymore.

Closing it

Thank you!