Design Placeholder is here:

• test the responses for clusters/networks/datastores and make sure they are valid
• test the responses for posting transformation_mappings
• change mock/dummy urls and remove the action creator exception responses (returning stubs now)

This issue will handle creating the UI components for the Migration in Progress Cards.

Subject to UX approval:
These will be using the Utilization Bar Card pattern referenced here:
http://www.patternfly.org/pattern-library/cards/utilization-bar-card/

There is also a PF React issue here for Base Card:
patternfly/patternfly-react#192

The Utilization Bar can be contributed to PF React as well (so I think we should start here for this issue):
patternfly/patternfly-react#193

We are using redux-form for now, but there was concern from me and from @priley86 while debugging issues with it that we may want to either replace it with another package or roll our own implementation of form validation with redux (which isn't too much boilerplate).

The issues that prompted that were resolved, so we stuck with it (for now?), but there are still comments reading // This may not be required if using Redux form, so we should resolve those.

Use .haml instead of .erb to be consistent with ManageIQ.

• ./test/migration/app/views/layouts/mailer.text.erb #59
• ./test/migration/app/views/layouts/mailer.html.erb #59
• ./test/migration/app/views/layouts/application.html.erb #59
• ./app/views/layouts/migration.erb #59
• ./app/views/layouts/index.html.erb https://github.com/priley86/miq_v2v_ui_plugin/pull/25

It was brought up here.

This should include actions + reducers + tests for API interactions around validating a list of vms (imported via a spreadsheet in the UI)

This should include actions + reducers + tests for API interactions around migration status (in progress/complete)

This issue will handle creating the UI components for the Migration in Completed Cards.

Subject to UX approval:
These will be using the Aggregate Status pattern referenced here:
http://www.patternfly.org/pattern-library/cards/aggregate-status-card/

There is also a PF React issue here for Base Card :
patternfly/patternfly-react#192

We will need to ensure the Base Card created supports Aggregate Status and then add any enhancements for Aggregate Status.

Note that this should not be started until the following is completed:
#30 Stub "Create Migration Plan" Wizard is complete

Implement the first step of the Migration Plan Wizard

This page has a

• mandatory infrastructure mapping
• mandatory name
• optional description.

Next should be disabled until the mandatory input is input.

Note that if there is only a single infrastructure mapping, then the dropdown should be preselected and disabled.

Note that this should not be started until the following is completed:
#30 (Stub Create Migration Plan Wizard)

*** Note that the below mocks may have been updated - need to updated on 06-Feb ***

Next should be disabled until a file is imported.
Clicking on Import will allow the user to browse for a file (does it have to be CSV?)
Once imported,

• the VMs will be shown in a read only list.
• the number of VMs will be displayed.
• Next will be enabled

The user MAY import another file ( but this will be covered by another Issue )

Ensure Overview page meets our Empty view high fidelity design:

• test the responses for /api/service_templates (to create a migration plan) and /api/provision_requests to create a Migration Request
• change mock/dummy urls and remove the action creator exception responses (returning stubs now)

This was not yet started. I will try to tackle this next.

This will involve the following:

• 1. create the general step for specifying mapping / description
• 2. create the import vm's step for importing vms and validating them if possible
• 3. create the results step indicating a migration is in progress

Note that this should not be started until the following is completed:
#2 Stub "Create Infrastructure Mapping" Wizard

Implement the first step of the Infrastructure Mapping Wizard

This page has a mandatory name and optional description.
Next should be disabled until the mandatory input is input.

Seen in Plan Wizard Step 2, when you upload a second CSV file and need to confirm overwriting the old one, or when you upload an invalid file.

Note that this is slightly higher priority because of how ugly the title is in the native dialogs: "0.0.0.0:8080 says..."

• Travis now runs our jest tests/eslint. In this issue we will integrate Hound CI for linting.
  ManageIQ/miq_bot#368

Note that this should not be started until the following is completed:
#33 Migration Plan Wizard - Step 2

If a file has already been imported, the Import button remains active.
If the user decides to import another file, post an confirmation message letting them know the list of VMs will be overwritten with the new import.
Once the user confirms, replace the existing list of VMs with the contents of the imported file.
If the user cancels the import, keep the list of existing VMs

In this issue we will ensure that all reducers are registered correctly via ManageIQ.redux.addReducer and that the store is also registered correctly via ManageIQ.redux.store.

cc: @vojtechszocs @ohadlevy

I will follow up with you soon in talk.manageiq.org or in Gitter.

Not sure if these are big enough to deserve individual issues, we can maybe create some for them when we actually get around to them. If anyone thinks any of these in particular should be made their own issues up front, let me know.

• Step 2 of the Plan Wizard (CSV upload step) uses some basic CSS to provide a hover state, and combines some existing design patterns, but we should give this CSS some designer attention and consider making a File Upload pattern in patternfly core eventually.
• The modal wizard window is always at a tall fixed height, it would be nice to have it adjust size to match its contents, even if we need to specify a specific pixel height for each step (although reactive CSS would be much nicer).
• The ModalWizard and ModalWizardBody are good candidates to be moved up to patternfly-react, but we would need to remove the application-specific bit of code near the top.
• Currently the way we prevent skipping ahead in the wizard with the Step Numbers is a little hacky. We should instead just track the state of the farthestSeenStepIndex and prevent clicking past that.
• We have some occasional JS console errors, mostly around missing key props in JSX arrays.

(If this repo is not supposed to become a ManageIQ repo, please close this issue.)

In all ManageIQ repos, squash + merge is disabled, because we do not want squashed commits. There is huge value in having the whole history, especially when looking for bugs, backporting changes to earlier releases, etc. etc.

We also don't allow editor config files to be checked in, except for a generic .editorconfig which multiple editors can parse. I'm seing .vscode here.

Third, we use yarn not npm, and we explicitly don't check in yarn.lock except in release branches. I'm seeing package-lock.json here.

This repository should follow the same rules.

Note that this should not be started until the following is completed:
#30 (Stub Create Migration Plan Wizard)

The results page just states that the plan is in progress.

Cancel & Back buttons shown be disabled, and the "Next" button label should change to Close. Close should also have focus.

Clicking on "Close" will close this wizard.

Note that once closed, the Overview page should be updated to include this Migration Plan in progress. (Not part of this Issue)

When no infrastructure mappings exist, the create migration plan empty state should

• disable the button
• update the secondary text to "Before you can create a migration plan, you need to create an infrastructure mapping." (text was given to us from our Content Strategist)

Simple wizard flow at this point first - so we can enable the other wizard steps to be developed simultaneously.

There are 3 steps in the wizard:

• General
• VMs
• Results

Stub the wizard steps indicators and the wizard back/next in the footer for infra mapping wizard that would be great. Let's just tackle that one first and try the planning wizard next...

I'm going to include Cluster Mapping, Datastore Mapping and Network Mapping in this issue/task because it will largely all be the same code (probably).

This maybe doesn't need to hit the API for the POC, just store the user-uploaded VM list.

Associated with the CSV upload and putting it in redux.

Note that this should not be started until the following is completed:
#2 (Stub Create Infrastructure Mapping Wizard)
#30 (Stub Create Migration Plan Wizard)

When status is successful, Cancel & Back buttons shown be disabled, and the "Next" button label should change to Close. Close should also have focus.

Clicking on the "Continue to the plan wizard" link should close this wizard, and invoke the Plan wizard, preselecting the Infrastructure Mapping just created.

Commented-out code is introduced by #42. We should remove it before merging upstream, but i'm letting it merge for now to unblock the next PR.

Note that this should not be started until the following is completed:
#11 (Create the Migration Completed Cards)

When clicking on the number of failed migrations in a Migration Completed card, show the VMs with associated message.

Design not yet completed - currently 2 possible designs

Note that this should not be started until the following is completed:
#26 (Infrastructure Mapping Wizard / Step 2)
#27 (Infrastructure Mapping Wizard / Step 3)

Implement the third step of the Infrastructure Mapping Wizard.

Check with @priley86 on what he's done in the past with a dual pane type selector. We will not be contributing anything to PF for the dual pane selector for now, because of time constraints.

For Step 4,
the user first selects a source cluster from a drop down

Once selected, the rest of the components will be shown in the panel including Source Networks, Target Networks the add mapping button and the mapped tree view component.

The user selects 1 or more Source Networks, and a single Target Networks, and then hits Add Mapping. The Add Mapping button should be disabled until those conditions exist. Upon hitting add mapping, the target cluster should be added as a parent, with the source clusters as children.

Note that Steps 2, 3 & 4 of this wizard will use very similar widgets.

See @priley86's comment on #42 in FormField.js. He proposes moving

app/javascript/react/screens/App/Overview/screens/formUtilities/FormField.js

to

app/javascript/react/screens/App/common/forms/FormField.js

but I am merging the PR without this to unblock us.

This should include actions + reducers + tests for API interactions around creating a migration request (after the migration plan wizard is completed and a request is created)

• previously the mappings were not reloaded if the user decided to Close instead of Continue.

In this issue we will follow up on the component registry pattern implemented here (and tested) and ensure it integrates with manageiq-ui-classic. Need to review if any components/containers need to be injected server-side (via mounts). Also need to review if we can support ownProps in the componentRegistry pattern implemented in manageiq-ui-classic.

Implement the second step of the Infrastructure Mapping Wizard.

Check with @priley86 on what he's done in the past with a dual pane type selector. We will not be contributing anything to PF for the dual pane selector for now, because of time constraints.

For Step 2, the user selects 1 or more Source Clusters, and a single Target Cluster, and then hits Add Mapping. The Add Mapping button should be disabled until those conditions exist. Upon hitting add mapping, the target cluster should be added as a parent, with the source clusters as children.

Note that Steps 2, 3 & 4 of this wizard will use very similar widgets.

Associated issues to be completed AFTER this issue :
#27 Infrastructure Mapping Wizard / Step 3
#28 Infrastructure Mapping Wizard / Step 4

I closed #47 because those comments were removed, but I'm going to leave this general issue open for any discussion about whether or not we should ditch redux-form. Had we started from scratch without it, I believe we would have been done in half the time... but we have sunk enough time into it and gotten it working after much frustration, so I see no immediate need to tear it out before the POC.

But if redux-form looks at me funny one more time I might delete it and rewrite the form validation with redux. It's form validation... it ain't that hard... and it wouldn't be more verbose so much as more explicit. It seems like redux-form decreases, rather than increases, the readability of our code (at least when it's breaking), because it tries to do too much magic. It is very unclear which components are passing what props where and how. Values magically get injected into input fields without a prop, so they can't be selectively overrided. And it's quite poorly documented (well, the docs are pretty, but the one i needed was a broken link).

The 2 big things we get out of redux-form are:

• Implicit storage of form data in redux (arguable if that is even desired)
• Pre-written validators for form data (not hard to roll our own, and there are alternatives like https://www.npmjs.com/package/react-validation). But if all we are doing is checking for required fields, it's trivial.

Low priority.. But I've had my 3 strikes with redux-form. I think I'd like to get rid of it in the long run. @priley86 I know you agree... @AparnaKarve I know you disagree. What do you like about redux-form? I bet we can easily emulate the good parts of it with our own code.

• test the responses for /api/transformation_mappings to query all mappings, and /api/service_requests to get the Overview Card statuses
• change mock/dummy urls and remove the action creator exception responses (returning stubs now)

@jeff-phillips-18 do you know of any others?

This should include actions + reducers + tests for API interactions around migration plans

Posting the execution of the migration plan

From @vconzola:

Show target cluster names as well as source cluster names in the dropdowns on the Datastores and Networks pages of the mapping wizard. For example, show "Raleigh (rehvh1-local)" instead of just "Raleigh". This will tie the dropdown to the tree view below when mappings are done.

This will probably need to be broken down further, but adding it as a high-level task to assign myself.

From @vconzola:

Don't allow datastore mapping if the space available in the target datastore is less than the size of the selected source datastores. Show an inline error on target selection (preferred) or when user selects the Add Mapping button.

Note that this should not be started until the following is completed:
#26 (Infrastructure Mapping Wizard / Step 2)

Implement the third step of the Infrastructure Mapping Wizard.

Check with @priley86 on what he's done in the past with a dual pane type selector. We will not be contributing anything to PF for the dual pane selector for now, because of time constraints.

For Step 3,
the user first selects a source cluster from a drop down

Once selected, the rest of the components will be shown in the panel including Source Datastores, Target datastores the add mapping button and the mapped tree view component.

The user selects 1 or more Source datastores, and a single Target datastore, and then hits Add Mapping. The Add Mapping button should be disabled until those conditions exist. Upon hitting add mapping, the target cluster should be added as a parent, with the source clusters as children.

Note that Steps 2, 3 & 4 of this wizard will use very similar widgets.

Associated issue to be completed AFTER this issue :
#28 Infrastructure Mapping Wizard / Step 4

We need to be able to query for all of the datastores for all source clusters in order to

1. Get a total count of datastores that need to be mapped
2. Warn the user about any unmapped source datastores

Please see pictures below

From the PoC Mocks