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

Move Openshift specific code into its provider directory. #15523

Merged
merged 1 commit into from
Aug 2, 2017

Conversation

lfu
Copy link
Member

@lfu lfu commented Jul 6, 2017

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

@gmcculloug
Copy link
Member

👍 After type ManageIQ/manageiq-schema#35 is merged.

@bzwei
Copy link
Contributor

bzwei commented Jul 20, 2017

LGTM

@lfu lfu force-pushed the refactor_container_manager branch from 4aa9ed0 to 72e4a51 Compare July 20, 2017 15:25
@lfu
Copy link
Member Author

lfu commented Jul 20, 2017

@enoodle Please review the refactoring of ContainerImage.
Do we need to add ManageIQ::Providers::Openshift::ContainerManager::ContainerImage subclass into Openshift repo?

@enoodle
Copy link

enoodle commented Jul 20, 2017

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

@lfu
Copy link
Member Author

lfu commented Jul 20, 2017

@enoodle Probably we want to take the ContainerImage refactoring out of this PR and leave it to you, maybe add it along with ManageIQ/manageiq-providers-openshift#23? So this PR can be merged without waiting and the ContainerImage functionality won't break. Thoughts?

@enoodle
Copy link

enoodle commented Jul 20, 2017

@lfu Yes, no problem

@lfu lfu force-pushed the refactor_container_manager branch from 72e4a51 to 457d48a Compare July 20, 2017 16:39
@Fryguy
Copy link
Member

Fryguy commented Jul 26, 2017

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

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 ?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Contributor

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)

@lfu lfu changed the title Move kube/openshift specific code into its provider directory. Move Openshift specific code into its provider directory. Jul 26, 2017
@lfu
Copy link
Member Author

lfu commented Jul 26, 2017

I thought Openshift template is the only container template that is currently supported.

@lfu lfu force-pushed the refactor_container_manager branch from 457d48a to 7bb28aa Compare July 31, 2017 14:54
@miq-bot
Copy link
Member

miq-bot commented Jul 31, 2017

Checked commit lfu@7bb28aa with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
2 files checked, 0 offenses detected
Everything looks fine. 🏆

@Fryguy Fryguy merged commit 1fdd17e into ManageIQ:master Aug 2, 2017
@Fryguy Fryguy added this to the Sprint 66 Ending Aug 7, 2017 milestone Aug 2, 2017
@@ -0,0 +1,2 @@
class ManageIQ::Providers::ContainerManager::ContainerTemplate < ContainerTemplate
Copy link
Contributor

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.

Copy link
Contributor

@cben cben Aug 3, 2017

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

@cben Good catch 👍

Copy link
Contributor

@cben cben Aug 3, 2017

Choose a reason for hiding this comment

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

lfu added a commit to lfu/manageiq that referenced this pull request Aug 3, 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