Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V2V - Workaround for network mappings storage #470

Closed
wants to merge 3 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Nov 12, 2018

When migrating a VM to OpenStack, we need the IP addresses of the source virutal machine to create the associated network ports. This PR add a statement to store the network mappings, which contain the IP addresses if VMware tools are running, into the task options hash for later consumption.

Associated RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1649020

@ghost
Copy link
Author

ghost commented Nov 12, 2018

@miq-bot add-label transformation, bug, hammer/yes, blocker

@coveralls
Copy link

coveralls commented Nov 12, 2018

Pull Request Test Coverage Report for Build 2338

  • 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.0009%) to 97.274%

Totals Coverage Status
Change from base Build 2333: 0.0009%
Covered Lines: 2926
Relevant Lines: 3008

💛 - Coveralls

@@ -25,6 +25,7 @@ def populate_factory_config

def main
raise 'Preflight check has failed' unless @task.preflight_check
@task.set_option(:network_mappings, @task.network_mappings)
Copy link
Member

Choose a reason for hiding this comment

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

@fdupont-redhat Seems odd to take the method data from a task and put it "into the task options hash for later consumption". Is this so it can be used through the API later? If so it would be better to expose it there then to store the data that the object already generates.

cc @roliveri @agrare

Copy link
Author

@ghost ghost Nov 13, 2018

Choose a reason for hiding this comment

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

It's a workaround until I find why it's not set by the call to preflight_check. Without it, migration fails and blocks QE.

@gmcculloug I've added a TODO comment to revisit later. Sorry for the technical debt.

Copy link
Member

Choose a reason for hiding this comment

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

@fdupont-redhat I need to understand what this really means:

why it's not set by the call to preflight_check`

I suggest we focus on this a little before jumping right to this work-around. We can discuss.

@miq-bot
Copy link
Member

miq-bot commented Nov 13, 2018

Checked commits fabiendupont/manageiq-content@cb4ee09~...7eed3db with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
2 files checked, 0 offenses detected
Everything looks fine. 🏆

@ghost
Copy link
Author

ghost commented Nov 13, 2018

@gmcculloug found the solution to preflight_check not setting the network mappings: it was not saved in the DB. Another PR fixes the issue: ManageIQ/manageiq#18194, so this one can be closed.

@ghost ghost closed this Nov 13, 2018
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants