[In Progress Cards] Migration should fail when denied due to lack of conversion host

[michaelkro]

If a migration is kicked off where there is no conversion host configured in the target environment, the request will be denied.

We need to investigate what happens in this case and make sure that the In Progress Card goes away and the proper notification(s) are shown to the user

https://bugzilla.redhat.com/show_bug.cgi?id=1640816

Duplicate of #739

[michaelkro]

Tried to investigate this on an appliance (cf-osp...). And need some help setting up test scenario. Here is what I observed

1. When creating a mapping, it appears that none of the target clusters have conversion hosts configured due to the warning icon
2. Created mapping
3. Created plan with the mapping and initiated migration
4. Migration request is approved, despite there being no configured conversion host
5. Drilling down into the active plan, I see that the task is polling in the Acquiring Conversion Host state

@fdupont-redhat, @bthurber

[bthurber]

@michaelkro I believe on this build that is to be expected but going forward if a conversion host isn't available and the user decided to try a migration it should be denied and fail.

@fdupont-redhat let us know if that is your understanding based on our conversation last week. It likely will require a code change to meet this behavior.

[ghost]

@michaelkro I confirm @bthurber's interpretation. In current build, it won't be denied. But with the following PRs merged, it should be in next one:

• Add a validation for conversion hosts manageiq#18135
• Expose validate_conversion_hosts for TransformationPlanRequest manageiq-automation_engine#263
• Deny request if no conversion host is configured manageiq-content#455
• Fix request denial manageiq-content#471

So, the code change should only be on UI side, to reflect the fact that the request is denied. And the reason in available in request's message.

[michaelkro]

Awesome, thanks @bthurber and @fdupont-redhat!

[michaelkro]

@fdupont-redhat I'm testing out denied requests and wanted to double check some things with you :)

1. I created a mapping using a target cluster with no conversion host. Then I created and ran a plan with that mapping
2. As expected, the request was never approved. I am using simulate_queue_worker in dev, and indeed, its activity quickly stops shortly after initiating the migration
3. However, the request's attributes do not seem to get updated to indicate that it has been denied.

[#<ServiceTemplateTransformationPlanRequest:0x00007f82d443f568
  id: 42000000000071,
  description: "Test",
  approval_state: "pending_approval",
  type: "ServiceTemplateTransformationPlanRequest",
  fulfilled_on: nil,
  requester_id: 42000000000001,
  requester_name: "Administrator",
  request_type: "transformation_plan",
  request_state: "pending",
  message: "VM Transformations - Request Created",
  status: "Ok",
  ...
  userid: "admin",
  source_id: 42000000000007,
  source_type: "ServiceTemplate",
  destination_id: nil,
  destination_type: nil,
  tenant_id: 42000000000001,
  service_order_id: 42000000000009,
  process: true,
  cancelation_status: nil>]

4. I also looked at the associated MiqApproval

// ServiceTemplateTransformationPlan.find('42000000000007').miq_requests.first.miq_approvals

[#<MiqApproval:0x00007f82d437e2f0
  id: 42000000000071,
  description: "Default Approval",
  state: "pending",
  reason: nil,
  miq_request_id: 42000000000071,
  stamped_on: nil,
  stamper_name: nil,
  stamper_id: nil,
  approver_id: nil,
  approver_type: nil,
  approver_name: nil,
  created_on: Tue, 13 Nov 2018 22:55:48 UTC +00:00,
  updated_on: Tue, 13 Nov 2018 22:55:48 UTC +00:00>]

I am wondering if maybe this is due to the development environment and worker?

[mturley]

Relevant mockup:

https://docs.google.com/presentation/d/1INIFpInmZ3oIjsxRw_SlTke6liGgvJLdasRD3uRVdzU/edit#slide=id.g45e2d2b245_0_6

[ghost]

@michaelkro You're probably hitting ManageIQ/manageiq-content#473. It is fixed and should be part of next build. With that, request.state will be denied and request.message will have the error message.

[mturley]

Marked this as a duplicate of #739, but since we've had comments in both issues, I'll leave both open for now.