Create a ConversionHost table

[agrare]

This adds a table for conversion hosts which can be polymorphically related to other inventory items i.e. Vms/Hosts.

[agrare]

@fdupont-redhat What other properties do we need to add to a conversion host?

[ghost]

@agrare If it's a VM, how do we get the credentials ? For the host it's already there, but AFAIK it's not for the VM. Or at least it's not visible in the UI.

[agrare]

@fdupont-redhat that's a different issue :) Lets tackle that in a different PR/Trello card.

[ghost]

@agrare LGTM, then.

[agrare]

@fdupont-redhat really nothing else? Maybe a version string?

[ghost]

We don't really have a notion of version, but capabilities might be good. Currently, we use tags to store the transport method, but it could be an attribute. Could it be a JSON field ? I don't know what we could store in there: virt-v2v capabilities, transport methods, other things that we don't know yet.

@nyoxi @aufi any idea ?

[aufi]

E.g. some Conversion host build number would be nice to detect old ones..

[nyoxi]

I can imagine storing various capabilities and versions could make sense. But that brings the question how will you keep them up-to-date with what's really on the host?

[agrare]

@nyoxi that would have to be done by whoever communicates with the code on the conversion host. This won't be able to be updated by inventory refresh because it won't be based on properties available to the RefreshWorker in provider inventory.

[agrare]

Okay @nyoxi I added a version string and a serialized capabilities so we can have some flexibility in what we store there. As long as we're not planning on doing any queries based on capabilities we should be good with that.

[ghost]

@agrare we do requests based on capabilities. Currently, the only capability we use in transport_method, which can be vddk, ssh, whatever we come up with. IIUC, it might be a good idea to have a specific column for that one, isn't it ?

[agrare]

@bdunne can you take a look?

[agrare]

Currently, the only capability we use in transport_method, which can be vddk, ssh, whatever we come up with. IIUC, it might be a good idea to have a specific column for that one, isn't it ?

Yes it would, I was going off of:

I can imagine storing various capabilities

which seemed pretty vague 😄

If a transport_method string column is all that you need then I'll add that.

[ghost]

That's all I need. It's the only attribute that is used during host selection, apart from current number of migrations which is calculated.

[agrare]

@fdupont-redhat is that going to be a single value or is it possible for multiple to be supported?

[ghost]

In the current implementation, we use a single value as it also decides the transport method to use for the migration. But IMO, it should be a per-mapping/plan/vm choice. So, being able to use the same host for many transport methods should be possible, as I don't see why a conversion wouldn't be able to use more than one transport method.

Please make it a multiple value attribute.

[agrare]

Please make it a multiple value attribute.

Going to need multiple columns then, don't want to be doing LIKE queries on a comma separated list :/

[ghost]

You mean one boolean column per transport method, right ?

[agrare]

@fdupont-redhat correct, is this something that can be inferred from the version? Or is it something that could be different for conversion hosts on the same version?

[bdunne]

t.references :resource, :type => :bigint, :polymorphic => true

[agrare]

👍 that's slick

[ghost]

@agrare It's not related to the version. Version will most likely refer to ovirt-ansible-v2v-conversion-host package version.

[agrare]

@fdupont-redhat okay I added two columns to represent if vddk and/or ssh transport is supported, PTAL

[ghost]

👍

[agrare]

Style/MethodCallWithArgsParentheses - Use parentheses for method calls with arguments.

@bdunne what do you think about disabling this cop? I think this goes against how we want migrations to be written.

[bdunne]

This feels very specific, is there some doc / design I can look describing how this will be used?

[agrare]

We wanted to add a method for throttling how many tasks run on a conversion host without having to loop through all active tasks and pull the conversion host out of the task options.

I don't see a trello card yet (/cc @fdupont-redhat) but there is an ongoing design doc here https://docs.google.com/document/d/1ANBPzDLF-id3MS9_8ztmrNjNwh3FJ6yGCvA2BUE808c/edit#heading=h.lzsppid3wjo9

Since this is still in design maybe we should hold off on this and come back and add this later.

[ghost]

Here's the Trello card: https://trello.com/c/DOClRvfD/189-migration-throttling-cf-model

[miq-bot]

Checked commits agrare/manageiq-schema@ad331a4~...cf1a489 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
1 file checked, 2 offenses detected

db/migrate/20180807153714_add_conversion_host_table.rb

• ❗ - Line 13, Col 7 - Style/MethodCallWithArgsParentheses - Use parentheses for method calls with arguments.
• ❗ - Line 7, Col 7 - Style/MethodCallWithArgsParentheses - Use parentheses for method calls with arguments.

[ghost]

@agrare As the resource attribute is polymorphic, what is the purpose of address ? I'd expect it to be the IP address to connect to the conversion host, but for an oVirt host it maps to resource.ipaddress, while for an OpenStack VM it could map to resource.ipaddresses.first or resource.ipv4_address...

How would you implement the polymorphism ? In the ConversionHost class using send and resource_type ?

[agrare]

@fdupont-redhat it was for the case where the conversion host is not in MIQ inventory e.g. a bare metal conversion host.

It looks like both the host and the vm models have an #ipaddresses method that you can use. I'd recommend a method on ConversionHost#ipaddress which could do address || resource.ipaddresses.first that should cover all cases

[ghost]

@agrare Thanks for the refresh. I'll create IP address methods in ConversionHost class.