ServiceTemplateTransformationPlanRequest fails with explicit resource type

[ghost]

When starting a migration it fails as the request is denied. And the request is denied because no conversion host is associated to the destination ext_management_system. Below is an example of the failing relationship:

irb(main):029:0> ConversionHost.first.ext_management_system.conversion_hosts
  ConversionHost Load (0.3ms)  SELECT  "conversion_hosts".* FROM "conversion_hosts" ORDER BY "conversion_hosts"."id" ASC LIMIT $1  [["LIMIT", 1]]
  ConversionHost Inst Including Associations (0.1ms - 1rows)
  ManageIQ::Providers::Openstack::CloudManager::Vm Load (0.5ms)  SELECT  "vms".* FROM "vms" WHERE "vms"."template" = $1 AND "vms"."type" IN ('ManageIQ::Providers::Openstack::CloudManager::Vm') AND "vms"."id" = $2 LIMIT $3  [["template", "f"], ["id", 162], ["LIMIT", 1]]
  ManageIQ::Providers::Openstack::CloudManager::Vm Inst Including Associations (0.3ms - 1rows)
  ExtManagementSystem Load (0.3ms)  SELECT  "ext_management_systems".* FROM "ext_management_systems" WHERE "ext_management_systems"."id" = $1 LIMIT $2  [["id", 6], ["LIMIT", 1]]
  ExtManagementSystem Inst Including Associations (0.3ms - 1rows)
  ConversionHost Load (0.4ms)  SELECT "conversion_hosts".* FROM "conversion_hosts" INNER JOIN "hosts" ON "conversion_hosts"."resource_id" = "hosts"."id" WHERE "hosts"."ems_id" = $1 AND "conversion_hosts"."resource_type" = $2  [["ems_id", 6], ["resource_type", "Host"]]
  ConversionHost Inst Including Associations (0.0ms - 0rows)
  ConversionHost Load (0.6ms)  SELECT "conversion_hosts".* FROM "conversion_hosts" INNER JOIN "vms" ON "conversion_hosts"."resource_id" = "vms"."id" WHERE "vms"."type" IN ('Vm', 'ManageIQ::Providers::CloudManager::Vm', 'ManageIQ::Providers::InfraManager::Vm', 'VmServer', 'ManageIQ::Providers::Amazon::CloudManager::Vm', 'ManageIQ::Providers::Azure::CloudManager::Vm', 'ManageIQ::Providers::Google::CloudManager::Vm', 'ManageIQ::Providers::Openstack::CloudManager::Vm', 'ManageIQ::Providers::Vmware::CloudManager::Vm', 'VmXen', 'ManageIQ::Providers::Kubevirt::InfraManager::Vm', 'ManageIQ::Providers::Redhat::InfraManager::Vm', 'ManageIQ::Providers::Microsoft::InfraManager::Vm', 'ManageIQ::Providers::Vmware::InfraManager::Vm') AND "vms"."template" = $1 AND "vms"."ems_id" = $2 AND "conversion_hosts"."resource_type" = $3  [["template", "f"], ["ems_id", 6], ["resource_type", "VmOrTemplate"]]
  ConversionHost Inst Including Associations (0.0ms - 0rows)
=> []

Actually, the conversion_hosts table contains ManageIQ::Providers::Openstack::CloudManager::Vm for the resource type of the existing conversion host.

The impact is that no migration will work.

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

[ghost]

@miq-bot assign @djberg96

[djberg96]

A simple way to reproduce this is to add a Redhat Infra provider. Then create a ConversionHost object on the console like so:

host = Host.first

# Not to panic, this won't enable it.
conversion_host = ConversionHost.create!(
  :name     => host.name,
  :resource => host,
  :address  => host.ipaddresses.first
)

Now, if you look at the resource_type on the conversion host object, you will see that it's set to "Host". Consequently, this will work fine:

conversion_host.ext_management_system.conversion_hosts

However, in the REST API, we explicitly use the STI subtype, e.g. "ManageIQ::Providers::Redhat::InfraManager::Host". This is because we wanted to take advantage of the SupportsFeature module where we could validate that the resource type actually supported conversion hosts.

The problem is that the has_many :through relationship set in ExtManagementSystem seems to not understand subtypes, and so we get no results. You can replicate it by doing this:

conversion_host.resource_type = conversion_host.resource.type
conversion_host.save
conversion_host.ext_management_system.conversion_hosts

You can see the relationships set at https://github.com/ManageIQ/manageiq/blob/master/app/models/ext_management_system.rb#L87-L88

[djberg96]

Actually, this almost looks like two issues. Besides not dealing with the resource type, it doesn't even appear to join the hosts table in the underlying SQL.

[djberg96]

One possible solution would be to drop the railsy association, and use custom sql:

  def host_conversion_hosts
    self.class.find_by_sql(%Q{
      select "conversion_hosts".*
      from conversion_hosts, hosts
      where conversion_hosts.resource_id = hosts.id
      and conversion_hosts.resource_type IN ('Host', 'ManageIQ::Providers::Redhat::InfraManager::Host')
      and hosts.type IN ('Host', 'ManageIQ::Providers::Redhat::InfraManager::Host')
    })
  end

  def vm_conversion_hosts
    self.class.find_by_sql(%Q{
      select "conversion_hosts".*
      from conversion_hosts, vms
      where conversion_hosts.resource_id = vms.id
      and conversion_hosts.resource_type IN ('VmOrTemplate', 'ManageIQ::Providers::Openstack::CloudManager::Vm')
      and vms.type IN ('VmOrTemplate', 'ManageIQ::Providers::Openstack::CloudManager::Vm')
    })
  end

[djberg96]

@fdupont-redhat It looks like we're supposed to ultimately preserve the base type. Look at https://github.com/ManageIQ/manageiq/blob/master/app/models/conversion_host/configurations.rb#L32-L40.

Try changing params[:resource_type] = resource.class.name to params[:resource_type] = resource.class.base_class.name