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

Adds host to physical server relationship #14026

Merged
merged 9 commits into from
Mar 24, 2017
Merged

Adds host to physical server relationship #14026

merged 9 commits into from
Mar 24, 2017

Conversation

rodneyhbrown7
Copy link

@rodneyhbrown7 rodneyhbrown7 commented Feb 22, 2017

-modifies the host and physical server controller
-updates the physical server and host model

@rodneyhbrown7 rodneyhbrown7 changed the title Adds host to physical server relationship [WIP] Adds host to physical server relationship Feb 22, 2017
@rodneyhbrown7
Copy link
Author

@miq-bot add_label wip, providers/physical-infrastructure

@juliancheal
Copy link
Member

This PR relies on #13973 being merged.



# Physical infra reference
has_one :physical_server, :foreign_key => "serialNumber", :primary_key => "service_tag", :class_name => "PhysicalServer"
Copy link
Member

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.

@rodneyhbrown7
Copy link
Author

Closing to re-run travis tests

@rodneyhbrown7
Copy link
Author

Re-open to run travis tests based on upstream resolutions

@rodneyhbrown7 rodneyhbrown7 reopened this Feb 23, 2017


# Physical infra reference
has_one :physical_server, :foreign_key => "serial_number", :primary_key => "service_tag", :class_name => "PhysicalServer"
Copy link
Member

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

@@ -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"
Copy link
Member

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

Copy link
Author

@rodneyhbrown7 rodneyhbrown7 Mar 2, 2017

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?

Copy link
Contributor

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.

Copy link
Member

@walteraa walteraa Mar 2, 2017

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).

Copy link
Member

@blomquisg blomquisg Mar 3, 2017

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!

@juliancheal
Copy link
Member

This PR LGTM, but needs PR #13973 being merged first.

@rodneyhbrown7
Copy link
Author

Closing to re-run travis tests

@rodneyhbrown7
Copy link
Author

Re-opening to re-run travis tests

@rodneyhbrown7 rodneyhbrown7 reopened this Mar 15, 2017
@miq-bot
Copy link
Member

miq-bot commented Mar 16, 2017

This pull request is not mergeable. Please rebase and repush.

Rodney H. Brown added 3 commits March 17, 2017 11:15
-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
@rodneyhbrown7
Copy link
Author

@miq-bot remove-label wip

@rodneyhbrown7
Copy link
Author

@miq-bot remove_label wip

@miq-bot miq-bot changed the title [WIP] Adds host to physical server relationship Adds host to physical server relationship Mar 21, 2017
@miq-bot miq-bot removed the wip label Mar 21, 2017
response_payload['host'] = case physical_server.host
when nil then nil
else physical_server.host.id
end
Copy link
Member

@chessbyte chessbyte Mar 21, 2017

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)

Copy link
Member

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.

@abellotti
Copy link
Member

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.

@rodneyhbrown7
Copy link
Author

rodneyhbrown7 commented Mar 21, 2017

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.

@blomquisg
Copy link
Member

One last thing: There was some discussion around the semantics of the belongs_to and has_one. @juliancheal changed it so that the hosts table has the physical_server_id. Whereas previously, the physical_servers table had the host_id.

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

@rodneyhbrown7
Copy link
Author

Reversing the polarity of the relationship between the servers and the host.

@walteraa
Copy link
Member

walteraa commented Mar 23, 2017

@rodneyhbrown7 @blomquisg I have a doubt about migration: Considering this change that Rodney did, should we change the migration about this relationship?

@blomquisg
Copy link
Member

@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
Copy link
Member

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)

@miq-bot
Copy link
Member

miq-bot commented Mar 23, 2017

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
3 files checked, 0 offenses detected
Everything looks good. 🍪

@blomquisg blomquisg merged commit 684f835 into ManageIQ:master Mar 24, 2017
@blomquisg blomquisg added this to the Sprint 57 Ending Mar 27, 2017 milestone Mar 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants