-
Notifications
You must be signed in to change notification settings - Fork 897
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
Adds host to physical server relationship #14026
Conversation
@miq-bot add_label wip, providers/physical-infrastructure |
This PR relies on #13973 being merged. |
app/models/host.rb
Outdated
|
||
|
||
# Physical infra reference | ||
has_one :physical_server, :foreign_key => "serialNumber", :primary_key => "service_tag", :class_name => "PhysicalServer" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:foreign_key
should be serial_number
not serialNumber
.
Closing to re-run travis tests |
Re-open to run travis tests based on upstream resolutions |
app/models/host.rb
Outdated
|
||
|
||
# Physical infra reference | ||
has_one :physical_server, :foreign_key => "serial_number", :primary_key => "service_tag", :class_name => "PhysicalServer" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This relationship is correct, in that a Host has_one :physical_server
. However, the foreign key of "serial_number"
is incorrect.
This should just be:
has_one :physical_server, :inverse_of => :host
app/models/physical_server.rb
Outdated
@@ -6,6 +6,7 @@ class PhysicalServer < ApplicationRecord | |||
belongs_to :ext_management_system, :foreign_key => :ems_id, :class_name => "ManageIQ::Providers::PhysicalInfraManager" | |||
|
|||
default_value_for :enabled, true | |||
has_one :host, :foreign_key => "service_tag", :primary_key => "serial_number" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This relationship should be belongs_to
, so it would look like:
belongs_to :host
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Greg, does a physical server belong to a host or does the host belong to the physical server? I was thinking that a physical server has a host, which has 1 - many VMs. It is possible to have a physical server with no host and a host with no VMs. Is my thinking backwards on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have the same thought that @rodneyhbrown7 has. We need to sync this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blomquisg I agree with @rodneyhbrown7, because in the real life a "host" is installed into a "physical server", not the other way around. By the way, in real life (also) there is a possibility of exists a "blank" physical server, with no hypervisor installed(which means that we'll not have a host context to this physical server).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The names has_one
and belongs_to
are merely reflecting where the foreign key lives. If we want to move the foreign key over to the hosts
table, then the model verbiage would reverse.
See also:
http://guides.rubyonrails.org/association_basics.html#the-belongs-to-association
http://guides.rubyonrails.org/association_basics.html#the-has-one-association
Here's the trick. Right now, it's the Physical Infrastructure Inventory saving code that's going to create this relationship. If the foreign key is moved from PhysicalServer
to Host
, it means that the Physical Infrastructure Inventory saving code would be changing an object in another manager's inventory.
This might not cause any problems. But, it's definitely a first for MIQ.
There are lots of long term ideas to make this relationship building less "brute force". But, unfortunately, no one has had time to dig into any of them to make it a reality. #soon!
This PR LGTM, but needs PR #13973 being merged first. |
Closing to re-run travis tests |
Re-opening to re-run travis tests |
This pull request is not mergeable. Please rebase and repush. |
-modifies the host and physical server controller -updates the physical server and host model
-use /api/hosts/<id>?attribute=physical_servers instead of /api/hosts/<id> to retrieve the list of associated physical_servers
@miq-bot remove-label wip |
@miq-bot remove_label wip |
response_payload['host'] = case physical_server.host | ||
when nil then nil | ||
else physical_server.host.id | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this case statement can be simplified to:
response_payload['host'] = physical_server.host.try(:id)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chessbyte is better response_payload['host']
or response_payload['host_id']
? Once we will need the ID of the host to perform other request in host resource.
I'm a bit confused on the API changes here as they are partial, no config/api.yml changes so the collection itself is not exposed (i.e. GET /api/physical_servers/1 gives a 404). was the intent to expose this in the API ? Other than above, the code itself in the API could be a lot simpler leveraging @additional_attributes and defining host_id as a virtual attribute (delegate) in the model. |
This is due to the fact that we chunked up a larger commit into smaller commits and didn't do a good job of correlating all of the PRs. The actual api.yml file changes are in #14028 This PR updates the controller to make the host relationship in the model and adds the relationship to a controller. As to the comment about the host_id. I think we determined that because of the association between hosts and servers we con't need an actual delegate? host_id is a property of physical_server because of the association. |
One last thing: There was some discussion around the semantics of the That means that the direction of the relationship now reads correctly, but needs to be reversed from what you have here. It now should be: class Host
belongs_to :physical_server, inverse_of => :host
end class PhysicalServer
has_one :host, inverse_of => :physical_server
end |
Reversing the polarity of the relationship between the servers and the host. |
@rodneyhbrown7 @blomquisg I have a doubt about migration: Considering this change that Rodney did, should we change the migration about this relationship? |
@walteraa, nope. The foreign key is already on the correct table. |
response_payload['host_id'] = case physical_server.host | ||
when nil then nil | ||
else physical_server.host.id | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, @chessbyte had a comment a while ago about this case
statement.
The case statement could be:
response_payload['host_id'] = physical_server.host.try(:id)
Refactor relationship statement to a elegant way.
Checked commits https://github.com/lenovo/manageiq/compare/79fb96226d51d819330abedf67c4393fa66ebbb6~...3c72c7e9e16c6bef33cb4de29c4ca34f3aba49e3 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
-modifies the host and physical server controller
-updates the physical server and host model