feat(web): adapt storage content according to the scenario

[joseivanlopez]

Adapt the content of the storage page according to the situation:

• No available devices: show empty state with options to configure devices (iSCSI, DASD, etc).
• Editable config and successful result: show Installation Devices and Result sections.
• Editable config and no result: show error and Installation devices section.
• No editable config and successful result: show alert with reset option and Result section.
• No editable config and no result: show empty state with config errors (if any) and reset option.

The encryption section is dropped for now.

Note: for now, the config is considered as non-editable if there are config errors. In the future, some components like ConfigEditor could be improved to make possible fixing an invalid config.

Screenshots

Normal screen

Correct settings but impossible setup

Unhandled settings but possible setup

Unhandled settings and impossible setup

Invalid settings

No target disks in s390

No target disks in other architectures

[ancorgs]

I think we have gone too far accumulating functionality on this file (just look at the size of the "import" section). Can't we extract the empty pattern component(s) to separate files? Similar to what is done for ProposalTransactionalInfo and ProposalFailedInfo?

[joseivanlopez]

I don't know if extracting single-usage-components like these, which don't have any kind of logic, is good or not.

IMHO, in cases like this, I prefer to have such components defined directly there in the only file where they are needed. Otherwise, there is a lot of chance of forgetting about them when the main component is refactored (that has already happened). Of course, there could be exceptions, like having complex components with too much logic.

But I can extract them if you guys prefer to go with that approach.

[joseivanlopez]

We decided to keep that components directly there, but in the future we will extract them to separate files, testing each component separately. Moreover, each component will have the logic to decide whether to render any content. The proposal page will simply mount all those components.

[dgdavid]

Why did you guys decide to postpone something agreed less than 3 hours ago? Just curious because it is, again, a kick to the front-end code.

I start having the feeling that does not payoff to invest time in meetings.

[imobachgs]

In a few words: "time pressure" 😓

[joseivanlopez]

Why did you guys decide to postpone something agreed less than 3 hours ago? Just curious because it is, again, a kick to the front-end code.

JFTR: because just after talking to you, the PO decided to go with the current code if it works. As @imobachgs said, time pressure. We agreed a) to add a FIXME, b) follow the agreed approach from now on, c) redo this code (and many other things) once time permits.

I start having the feeling that does not payoff to invest time in meetings.

I disagree. Our agreement is ok and we will follow it from now on.

[coveralls]

Pull Request Test Coverage Report for Build 13334350448

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-47.4%) to 25.046%

---

Totals
Change from base Build 13305098023:	-47.4%
Covered Lines:	1752
Relevant Lines:	6995

---

💛 - Coveralls

[ancorgs]

This LGTM.

I'm not merging because the last commit was added by me (together with all the screenshots at the description). Somebody would need to review those texts. Once the texts are reviewed, we can merge.

[imobachgs]

Just some suggestions.

[imobachgs]

those or these?

[ancorgs]

I would say "those" because the settings are not really displayed. And the reference to them is at a previous paragraph. Both sound like "distance" to me.