Rewriting Cloud Volume Form to React

[DavidResende0]

Form can be found in Storage->Block Storage->Volumes

Fixes #7334

[DavidResende0]

@miq-bot add_reviewer @skateman

[skateman]

I created a core PR that should allow us more precise querying of the supported providers for create and edit separately. Please change the logic accordingly.

[skateman]

Due to some complex conditions in the amazon form, we need to tap into some dark magic to hide the standard (Magnetic) volume type from the dropdown when editing a non-magnetic amazon volume.

[skateman]

This is getting close, just please avoid applying suggested changes using the browser as it creates a mess in the code/commits.

[skateman]

There are a bunch of linting errors in the codebase, please integrate eslint into your editor to see them.

[skateman]

@DavidResende0 can you please rebase this PR?

[skateman]

Fields are now provider-specific, coming from the API, so there are some differences. The steps/size things is also coming from the provider, it's their decision to have bytes/gbytes, not a UI problem 😉

[himdel]

The steps/size things is also coming from the provider, it's their decision to have bytes/gbytes, not a UI problem

Right, so..

• Amazon, uses bytes, from Declared DDF schema for cloud volume creation and editing manageiq-providers-amazon#657
• IBM Cloud, used bytes since Declared DDF schema for cloud volume creation and editing manageiq-providers-ibm_cloud#84, fixed in Fix cloud volume operations manageiq-providers-ibm_cloud#129
• Openstack, uses bytes, from Declared DDF schema for cloud volume creation and editing manageiq-providers-openstack#644

I can't help but notice the "provider decision" was made by you :)

Let's fix it before merging, bad UI is always a UI problem :).

[skateman]

Different provider backend expect different values (bytes, gigabytes) so I don't know what would be the fix here. Also it's not related to this PR as it is coming from the provider ...

Amazon/Openstack expects bytes, while IBM needs GBs

[chessbyte]

Amazon/Openstack expects bytes, while IBM needs GBs

We should make our provider plugins work from a single standard and do necessary conversions when communicating with the actual provider. I am assuming that standard is bytes. /cc @agrare

[skateman]

The point of provider pluggability and form schemas coming over the API is that these things aren't implemented in the UI repo anymore and they don't block us in merging this. With other words: there is nothing else to do in this repo so why can't we get this in @himdel?

[agrare]

I agree that all providers should use bytes for consistency (someone could be calling CloudVolume.create from automate and the options should be consistent).

We also don't have to do that before this PR is merged, it can be fixed in the IBM Cloud repo independently.

[agrare]

I can't help but notice the "provider decision" was made by you :)

He decided on bytes which was correct ;) Looks like IBM API takes GB but we should be converting that in raw_create_volume not in the form.

[agrare]

@himdel all providers are consistent now, please take another look

[skateman]

I can't help but notice the "provider decision" was made by you :)

He decided on bytes which was correct ;) Looks like IBM API takes GB but we should be converting that in raw_create_volume not in the form.

No, I didn't 😆 IBM folks were complaining that the form isn't working

[jaywcarman]

IBM guy here 😄. I understand the value in consistent provider back-ends, so I agree with ManageIQ/manageiq-providers-ibm_cloud#135. But now the user interface to create volumes for the IBM Cloud provider isn't great. Is there a way to define the provider form to display GB to the user, but submit the value as bytes? It seems arduous to ask a user to type 107374182400 (or click the step button 100 times) if they want a 100GB volume.

[skateman]

@jaywcarman @agrare @himdel do we have to do anything else in this PR or these problems can be solved in the provider repos? In that case what is blocking us from merging this UI PR?

[skateman]

The Carbon mapper got merged, you should rebase

[miq-bot]

Checked commit DavidResende0@140a2ee with ruby 2.6.3, rubocop 0.82.0, haml-lint 0.35.0, and yamllint
4 files checked, 1 offense detected

**

• 💣 💥 🔥 🚒 - Linter/Haml - Linter::Haml STDERR:

warning: parser/current is loading parser/ruby26, which recognizes
warning: 2.6.6-compliant syntax, but you are running 2.6.3.
warning: please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.

[skateman]

@jaywcarman @agrare @himdel do we have to do anything else in this PR or these problems can be solved in the provider repos? In that case what is blocking us from merging this UI PR?

bump

[jaywcarman]

@jaywcarman @agrare @himdel do we have to do anything else in this PR or these problems can be solved in the provider repos? In that case what is blocking us from merging this UI PR?

I don't have any issues with merging this PR. If we do that I can open an issue against the IBM Cloud provider to discuss whether/how to improve the display units.

[agrare]

@skateman merge away if you're good with this

[himdel]

@jaywcarman There's likely no way you can do the conversion in the provider repo, unfortunately :(.

The only way is for the UI to provide a bytes-to-human-size component the providers can then use. Looks like the UI changes will be up to you then, sorry about that. ( #7311 should be a good example of enhancing an existing component by wrapping it, in your case you'd be creating a new one by wrapping an existing number input, but otherwise the principle should be the same)

If you do end up fixing it, please make sure the component is used by all the providers :)

do we have to do anything else in this PR or these problems can be solved in the provider repos? In that case what is blocking us from merging this UI PR?

Sorry, I was too late. The logic was, without this PR, everybody can still use the old forms, with gigabytes and we don't have a TODO(before release).

I do agree with the need to settle on bytes on the data level, but IMO without a component to convert that, it makes the UI less than useable. And I'm not aware of any way to do that from a provider repo (other than doing what should be done here, except 3 times).

(Though, one possible consideration, values over 8 PB can't be represented exactly in js if the representation is numeric bytes.)

[skateman]

@himdel without this PR you can't really create IBM cloud volumes. Also who would actually create a volume that has 8 PB??? 😱