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

[WIP] fix association between EMS and ConfigurationSystem #16798

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions app/models/ext_management_system.rb
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,7 @@ def self.supported_types_and_descriptions_hash

belongs_to :provider
has_many :child_managers, :class_name => 'ExtManagementSystem', :foreign_key => 'parent_ems_id'
has_many :configured_systems, :dependent => :destroy, :foreign_key => "manager_id"
Copy link
Contributor

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

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.


belongs_to :tenant
has_many :container_deployments, :foreign_key => :deployed_on_ems_id, :inverse_of => :deployed_on_ems
Expand Down
1 change: 0 additions & 1 deletion app/models/manageiq/providers/automation_manager.rb
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,6 @@ class ManageIQ::Providers::AutomationManager < ManageIQ::Providers::BaseManager
require_nested :InventoryRootGroup
require_nested :OrchestrationStack

has_many :configured_systems, :dependent => :destroy, :foreign_key => "manager_id"
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",
Expand Down
1 change: 0 additions & 1 deletion app/models/manageiq/providers/configuration_manager.rb
Original file line number Diff line number Diff line change
@@ -1,5 +1,4 @@
class ManageIQ::Providers::ConfigurationManager < ManageIQ::Providers::BaseManager
has_many :configured_systems, :dependent => :destroy, :foreign_key => "manager_id"
has_many :configuration_profiles, :dependent => :destroy, :foreign_key => "manager_id"
has_many :configuration_scripts, :dependent => :destroy, :foreign_key => "manager_id"
has_many :configuration_script_sources, :dependent => :destroy, :foreign_key => "manager_id"
Expand Down