[WIP] fix association between EMS and ConfigurationSystem

[jameswnl]

The association is wrong and should be all set in their own base classes.

[bdunne]

This change is good, but are you going to move the rest of the relations as well? I would have expected that in the same PR.

[jameswnl]

@bdunne yes, that's what I am looking, seems like all the following,

  has_many :configuration_profiles,       :dependent => :destroy, :foreign_key => "manager_id"
  has_many :configuration_scripts,        :dependent => :destroy, :foreign_key => "manager_id"
  has_many :credentials,                  :class_name => "ManageIQ::Providers::AutomationManager::Authentication",
           :as => :resource, :dependent => :destroy
  has_many :inventory_groups,             :dependent => :destroy, :foreign_key => "ems_id", :inverse_of => :manager
  has_many :inventory_root_groups,        :dependent => :destroy, :foreign_key => "ems_id", :inverse_of => :manager
  has_many :configuration_script_sources, :dependent => :destroy, :foreign_key => "manager_id"
  has_many :configuration_script_payloads, :through => :configuration_script_sources

[miq-bot]

Checked commits jameswnl/manageiq@7207258~...832f547 with ruby 2.3.3, rubocop 0.52.0, haml-lint 0.20.0, and yamllint 1.10.0
3 files checked, 5 offenses detected

app/models/ext_management_system.rb

• ❗ - Line 32, Col 3 - Rails/InverseOf - Specify an :inverse_of option.
• ❗ - Line 33, Col 3 - Rails/InverseOf - Specify an :inverse_of option.
• ❗ - Line 34, Col 3 - Rails/InverseOf - Specify an :inverse_of option.
• ❗ - Line 35, Col 3 - Rails/InverseOf - Specify an :inverse_of option.
• ❗ - Line 36, Col 3 - Rails/InverseOf - Specify an :inverse_of option.

[Ladas]

I believe it was on purpose, that the relations were only on automation_manager, we do the same for cloud_manager, etc.

I think the base of you failing specs is that the mock data are not valid. Each model has to have a correctly filled STI type, like it always has when it comes from a refresh.

[jameswnl]

Yes, true that the failing specs can be fixed by using the corresponding factory for automation_manager.

But what I have question about is that, why on one side we define the relationship in base class ExtManagementSystem and the other side in the subclass AutomationManager? Is this a proper practice in rails?

The other point is that: If the concept of a EMS has many ConfiguredSystem is valid at base class level, we should be able to test it.

[Ladas]

Hm so I think the idea was to have manager specific relations only under the specific manager, e.g. cloud manager https://github.com/Ladas/manageiq/blob/be7d05ca1089fa0c06802c2bfa666d5b9e10f455/app/models/manageiq/providers/cloud_manager.rb#L17

Then the relations would not work, unless the proper STI types are set, so all specs have to set them right.

But I've seen that e.g. if relation is shared by more types of managers, it goes to ext_management_system.rb. Which is your case, so this should be acceptable.

Or e.g. for complex virtual attributes, it easier to have the relation on base class, otherwise it might give unexpected results.

[chrisarcand]

Is this still valid? @jameswnl @agrare

[agrare]

I think the consensus is that this is not needed in the base model since configured_system makes no sense for infra/cloud/physical/network/etc... managers.