Skip to content
This repository has been archived by the owner on Sep 5, 2024. It is now read-only.

Conversion Host Configuration Wizard Step #1 (Location), and introducing common reducers #871

Merged
merged 16 commits into from
Feb 5, 2019

Conversation

mturley
Copy link
Contributor

@mturley mturley commented Jan 31, 2019

Part of the Conversion Hosts UI feature BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1693339

This is part of #855.

This PR adds the contents of the Location step (Step 1) of the Configure Conversion Host wizard:

9wx9i0enag

This PR also adds a check for sufficient providers before displaying the Conversion Hosts tab of the settings page, to prevent errors in this wizard step when a user has insufficient providers configured. In this case, the empty state is shown with a button for configuring providers, similar to the Plans and Mappings views:

screenshot 2019-02-04 13 00 46

Since this PR would have otherwise duplicated a bunch of code related to providers and target clusters/projects, I also introduced a new pattern of reducers coupled to API resources rather than to views. We have a good amount of this kind of code duplication elsewhere in the codebase, but that's outside the scope of this PR, so I only created the providersReducer and the targetResourcesReducer (which so far only handles target clusters). We can move things into common reducers like these incrementally, rather than duplicate code, as the need arises.

@mturley mturley force-pushed the conv-host-wizard-step1 branch 2 times, most recently from b085fb6 to 50093c9 Compare February 1, 2019 20:35
@mturley mturley changed the title [WIP] Conversion Host Configuration Wizard Step #1 (Location) Conversion Host Configuration Wizard Step #1 (Location) Feb 1, 2019
@mturley mturley removed the wip label Feb 1, 2019
@miq-bot
Copy link
Member

miq-bot commented Feb 1, 2019

Checked commits mturley/manageiq-v2v@68da0c4~...2d29e21 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
0 files checked, 0 offenses detected
Everything looks fine. 🍪

@mturley
Copy link
Contributor Author

mturley commented Feb 1, 2019

This needs unit tests, but is otherwise ready to go.

@michaelkro, I'm adding you as a reviewer here since you were kind enough to offer, but since it's past 5pm on your last day, feel free to revoke that offer at your discretion! Once again it's been a real pleasure working with you. Cheers 🍻

payload: API.get(url)
});

export const fetchProvidersAction = url => {
Copy link
Contributor

@michaelkro michaelkro Feb 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Food for thought...

There is already a system in place for fetching and maintaining a list of providers in the Overview screen. Now that we need similar functionality here in Settings, we are duplicating that code, and maintaining the same data in two separate places.

When resources are shared across screens like this, it might make sense to have "application level" actions/reducers. These could be made available to the screens/components that need them in the same way we're already doing it (map state to props in the container components)

A few benefits for this approach

  1. Reduce code duplication
  2. It would reduce the size of our reducers and make them easier to read.
  3. Screen reducers would only need to concern themselves with the UI state and resource reducers would manage data

That being said, the work here is in line with the state management system that is already in place. I just wanted to point this out

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@michaelkro thanks for reviewing! I hope you're enjoying your time off.

That's a really good point, and something I considered while implementing this. I didn't go through with it because I thought it would be a huge refactor out of scope of this change (since we already have a bit of this duplication elsewhere), but actually I think it is a really good idea to do that incrementally. I think I'll create a SharedReducer and start with providers and target compute resources. Thanks for convincing me :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@michaelkro I did a major refactor to create the new providersReducer and targetResourcesReducer based on this advice. I'm curious what you think of this implementation.

@mturley mturley changed the title Conversion Host Configuration Wizard Step #1 (Location) [WIP] Conversion Host Configuration Wizard Step #1 (Location) Feb 4, 2019
@mturley mturley added the wip label Feb 4, 2019
class ConversionHostWizardLocationStep extends React.Component {
componentDidMount() {
const { fetchProvidersAction, fetchProvidersUrl } = this.props;
fetchProvidersAction(fetchProvidersUrl);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're fetching providers on mount, we could use this data to dynamically populate the provider type dropdown with only what is available.

Oh, that makes me think, what happens on the conversion hosts tab if there are no providers? Do we show the provider empty state like in Mappings and Overview?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a really good point, I hadn't considered that. I think as implemented, it would just show the conversion hosts empty state and prompt the user to open the conversion host wizard, where the providers dropdown would be empty. That's a case I need to handle.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also handled this.

Copy link
Contributor

@michaelkro michaelkro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that introducing the common redux reducers is going to be really valuable moving forward. Really nice job taking this on

Things I tested

  1. Creating mappings (OSP and RHV)
  2. Creating plans (OSP and RHV)
  3. Running RHV migration. Due to our new check that waits for an available conversion host, this test was inconclusive. However, everything up till that point seems ok
  4. Checked to see that provider type dropdown is only populated with what is available
  5. Checked to see that provider empty state is shown if available providers are insufficient
  6. Checked functionality of Wizard Step 1

Looks good to me!

@mturley
Copy link
Contributor Author

mturley commented Feb 5, 2019

@michaelkro thanks so much! I really appreciate your feedback, and your help moving towards a nicer pattern for the common reducers.

Now go relax!

@mturley mturley merged commit a0ee080 into ManageIQ:master Feb 5, 2019
@mturley mturley deleted the conv-host-wizard-step1 branch February 5, 2019 20:54
@mturley mturley added bz Issues filed by QE or having a BZ and removed bugzilla needed wip labels Feb 27, 2019
@mturley mturley added v1.2 and removed v1.1 labels Mar 25, 2019
simaishi pushed a commit that referenced this pull request Apr 5, 2019
Conversion Host Configuration Wizard Step #1 (Location), and introducing common reducers

(cherry picked from commit a0ee080)

https://bugzilla.redhat.com/show_bug.cgi?id=1696423
@simaishi
Copy link
Contributor

simaishi commented Apr 5, 2019

Hammer backport details:

$ git log -1
commit 5d8c17ae03a55c9c6316cddbd35f7cbc3cd8883c
Author: Mike Turley <mike.turley@alum.cs.umass.edu>
Date:   Tue Feb 5 15:54:52 2019 -0500

    Merge pull request #871 from mturley/conv-host-wizard-step1
    
    Conversion Host Configuration Wizard Step #1 (Location), and introducing common reducers
    
    (cherry picked from commit a0ee080c47502453d76ab6d7f0629471438c184f)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1696423

@simaishi
Copy link
Contributor

simaishi commented Apr 5, 2019

@mturley Can you please review the bakcport of this PR and make necessary changes in a new PR? I skipped renaming of providers.fixtures file as the file doesn't exist in hammer branch. But it looks some other changes are needed because of that...

/home/travis/build/ManageIQ/manageiq-v2v/app/javascript/redux/common/providers/__tests__/providersActions.test.js
  5:27  error  Unable to resolve path to module '../providers.fixtures'  import/no-unresolved

The conflits backporting this PR were:

	both modified:   app/javascript/react/screens/App/Overview/OverviewReducer.js
	both modified:   app/javascript/react/screens/App/Overview/__test__/OverviewReducer.test.js
	deleted by us:   app/javascript/react/screens/App/Overview/__test__/__snapshots__/OverviewReducer.test.js.snap
	added by them:   app/javascript/redux/common/providers/providers.fixtures.js

@mturley
Copy link
Contributor Author

mturley commented Apr 5, 2019

@simaishi sure, I'll take a look first thing in the morning.

@mturley
Copy link
Contributor Author

mturley commented Apr 5, 2019

@simaishi here's a PR to fix that problem: #929

I reviewed the other changes in your backport commit, everything else looks good. Thanks again for dealing with this mess :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants