-
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
Move Openshift specific code into its provider directory. #15523
Conversation
90069df
to
4aa9ed0
Compare
👍 After |
LGTM |
4aa9ed0
to
72e4a51
Compare
@enoodle Please review the refactoring of |
@lfu ManageIQ/manageiq-providers-openshift#23 is taking care of it but is waiting on #15519 Second thought: This change should also wait on it. Introducing a new container image class will change the way SSA jobs are built. Also we will need to update in manageiq-provider-kubernetes to set the correct type for the new container images. |
@enoodle Probably we want to take the |
@lfu Yes, no problem |
72e4a51
to
457d48a
Compare
I merged ManageIQ/manageiq-schema#35, but then realized the PRs makes all of the ContainerTemplate objects OpenShift specific...couldn't it be Kubernetes as well? |
@@ -0,0 +1,67 @@ | |||
class ManageIQ::Providers::ContainerManager::ContainerTemplate < ContainerTemplate |
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.
If this is Kubernetes specific code, why is it going in ManageIQ::Providers::ContainerManager::ContainerTemplate ?
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.
Thought these codes are for both Kubernetes and Openshift.
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.
Code in ManageIQ::Providers::ContainerManager is for any container manager...it could even be something like docker swarm in the future.
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.
Shared code for kubernetes and openshift should go into manageiq-providers-kubernetes.
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.
@Fryguy What is the relationship between ManageIQ::Providers::Kubernetes::ContainerManager::ContainerTemplate
and ManageIQ::Providers::Openshift::ContainerManager::ContainerTemplate
? Are they parallel?
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 would expect them to be unrelated. They may share code via a shared module, but other than that, they are independent.
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.
Specifically templates are an Openshift addition, they don't exist in Kubernetes.
(they might in future, openshift concepts tend to get upstreamed, there is already a proposal)
I thought Openshift template is the only container template that is currently supported. |
457d48a
to
7bb28aa
Compare
Checked commit lfu@7bb28aa with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
@@ -0,0 +1,2 @@ | |||
class ManageIQ::Providers::ContainerManager::ContainerTemplate < ContainerTemplate |
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.
Adding this (now empty) subclass had an interesting consequence (that's breaking openshift refresh).
In manageiq/providers/container_manager.rb,
ContainerTemplate
resolves to this nested class, not the base ::ContainerTemplate
.
And when we do
has_many :container_templates, :foreign_key => :ems_id, :dependent => :destroy
it apparently does such a const lookup (?), and the query now constrains type
, never matching any records:
(byebug) ems.container_templates.to_sql
"SELECT \"container_templates\".* FROM \"container_templates\" WHERE \"container_templates\".\"type\" IN ('ManageIQ::Providers::ContainerManager::ContainerTemplate') AND \"container_templates\".\"ems_id\" = 24000000000002"
I can do
has_many :container_templates, :foreign_key => :ems_id, :dependent => :destroy, :class_name => "::ContainerTemplate"
to get back the query
> ems.container_templates.to_sql
=> "SELECT \"container_templates\".* FROM \"container_templates\" WHERE \"container_templates\".\"ems_id\" = 3"
but I wonder what's the point of having both ::ContainerTemplate
and ManageIQ::Providers::ContainerManager::ContainerTemplate
?
It's not like any non-container providers will have ContainerTemplate, so why not axe this subclass and have kubernetes/openshift inherit from ::ContainerTemplate
?
@lfu @Fryguy @kbrock @moolitayer please advice.
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.
Got curious if ContainerManager::OrchestrationStack relation is also affected.
ContainerManager doesn't include HasManyOrchestrationStackMixin
, but if it did:
[2] pry(main)> ems.orchestration_stacks.to_sql
=> "SELECT \"orchestration_stacks\".* FROM \"orchestration_stacks\" WHERE \"orchestration_stacks\".\"type\" IN ('ManageIQ::Providers::ContainerManager::OrchestrationStack', 'ManageIQ::Providers::Openshift::ContainerManager::OrchestrationStack') AND \"orchestration_stacks\".\"ems_id\" = 3"
Strange, this correctly includes the openshift descendants so seems harmless. Why doesn't the templates query?
[5] pry(main)> ManageIQ::Providers::ContainerManager::ContainerTemplate.descendants
=> []
... some false steps later ...
[13] pry(main)> ManageIQ::Providers::Openshift::ContainerManager::ContainerTemplate
=> ManageIQ::Providers::ContainerManager::ContainerTemplate(...
OMG, the provider-specific subclasses are not loaded! Const lookup is satisfied by finding this class instead, so no autoload.
[16] pry(main)> require 'manageiq/providers/openshift/container_manager/container_template.rb'
=> true
[17] pry(main)> ManageIQ::Providers::Openshift::ContainerManager::ContainerTemplate
=> ManageIQ::Providers::Openshift::ContainerManager::ContainerTemplate(...
[18] pry(main)> ManageIQ::Providers::ContainerManager::ContainerTemplate.descendants
=> [ManageIQ::Providers::Openshift::ContainerManager::ContainerTemplate(...)]
=> Gonna add require_nested
.
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.
@cben Good catch 👍
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.
(yay we resolved it, given ManageIQ/manageiq-providers-kubernetes#81 now ManageIQ/manageiq-providers-openshift#28 passes.)
Follow-up of ManageIQ#15523.
Move Openshift specific code into its provider directory to be consistent with the standard file layouts for providers.
Depends on ManageIQ/manageiq-schema#35.
Blocks ManageIQ/manageiq-providers-openshift#28.
Blocks ManageIQ/manageiq-providers-kubernetes#79.
@miq-bot assign @gmcculloug
@miq-bot add_label refactoring, providers/containers
cc @bzwei @simon3z