-
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
ConfigurationWorkflow to exist only in AutomationManager space #17720
Conversation
@@ -11,7 +11,8 @@ class ManageIQ::Providers::AutomationManager < 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_scripts, :dependent => :destroy, :foreign_key => "manager_id", | |||
:class_name => "::ConfigurationScript" |
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 @blomquisg @gmcculloug @bzwei
This would get back both job_templates and workflows, but I don't like that it's breaching into the base class space.
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.
you don't need the class_name bit, because it's implied.
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.
That is exactly how we'd expected it to work from the original discussion...not sure I understand your concern.
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.
Without the class_name
, it will default to the AutomationManager::ConfigurationScript
(and that gives only the job_templates
)
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
Our comments are interwinding and so let me try to clarify again:
- We need to pin the
class_name
to the base class in order to get what we want (get back both job_templates/workflows) - Pinning the relationship (the
class_name
) from a subclass level object to a base class level object (i.e.ManageIQ::Providers::AutomationManager
vs::ConfigurationScript
) is kind of breaching the abstraction layers. It's not the end of the world. But why don't we simply move the relationship to the 2 base classes (EMS
vsConfigurationScript
) ?
@@ -43,7 +43,7 @@ def has_configuration_script_payloads(options = {}) | |||
|
|||
def has_configuration_workflows(options = {}) | |||
has_inventory({ | |||
:model_class => ::ConfigurationWorkflow, | |||
:model_class => ManageIQ::Providers::AutomationManager::ConfigurationWorkflow, |
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.
has_configuration_scripts
should have a similar model_class to isolate it to AutomationManager::ConfigurationScript because you want to filter only those on that half of the equation.
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.
Actually...this hardcoding should not be in core...I think I'm missing something fundamental about the refresh modeling to understand 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.
@Fryguy But then this would deviate from the relationship defined in AutomationManager
(which includes both job_templates
and workflows
). Do we want that?
(Either way, I am actually have issue with here pointing to a specific subclass in this core
location. But I don't have a better solution since we eliminate ::ConfigurationWorkflow
)
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.
haha yeah, you comment is exactly my concern, hardcoding the specific subclass in core....
@Ladas can you help?
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.
@Ladas bump
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.
let us brainstorm with @agrare and @slemrmartin 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.
Well for one we got rid of this way of defining inventory collections so this will never get used :)
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.
@agrare hm right, I got lost in what got merged. So the new way seems to already solve this? https://github.com/Ladas/manageiq/blob/dd1215d37906f6fd7ee757cdd5510a019bfa7039/app/models/manager_refresh/inventory/automation_manager.rb#L38 , right @slemrmartin ?
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.
@jameswnl as @agrare wrote has_inventory
interface is deprecated and will be removed.
Please use add_collection
and ManagerRefresh::InventoryCollection::Builder::AutomationManager
instead.
Model class is derived automatically, but, as I described #17574 (comment), autoloading (including calling new
) is weird when you doesn't have IC object's class defined for each persister's subclass (..::EmbeddedAutomationManager, ...::EmbeddedAnsible etc.).
You can hardcode :model_class
as you defined above in ManageIQ::Providers::AnsibleTower::Inventory::Persister::AutomationManager
And redefine it, if you need, in persister's subclasses
ce57cf5
to
a354946
Compare
app/models/configuration_script.rb
Outdated
@@ -2,4 +2,5 @@ class ConfigurationScript < ConfigurationScriptBase | |||
def self.base_model | |||
ConfigurationScript | |||
end | |||
belongs_to :manager, :class_name => "ManageIQ::Providers::AutomationManager", :inverse_of => :configuration_scripts |
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 @blomquisg @gmcculloug I have to changed here :class_name
to ManageIQ::Providers::AutomationManager
to fix spec failure here https://travis-ci.org/ManageIQ/manageiq/jobs/405012910#L870
6ece83f
to
5c0831f
Compare
:foreign_key => "manager_id", | ||
:class_name => "::ConfigurationScript", | ||
:inverse_of => :manager | ||
|
||
has_many :configuration_workflows, :dependent => :destroy, :foreign_key => "manager_id", :inverse_of => :manager |
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.
won't this fails, when ConfigurationWorkflow
was deleted, I think this will need :class_name => "::ConfigurationScript",
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.
It infers to default AutomationManager::ConfigurationWorkflow
.
We may have to remove this because now it's "unfair" that we have a query to get back workflows
(aka AutomationManager::ConfigurationWorkflow
) but no job_templates
(aka AutomationManager::ConfigurationScript
)
has_many :configuration_scripts, | ||
:dependent => :destroy, | ||
:foreign_key => "manager_id", | ||
:class_name => "::ConfigurationScript", |
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 looks redundant, the class should be inferred automatically
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 inferred class would be AutomationManager::ConfigurationScript
. The requirement here is to return both AutomationManager::ConfigurationScript
and AutomationManager::ConfigurationWorkflow
This pull request is not mergeable. Please rebase and repush. |
d90d02b
to
3ece6a5
Compare
@@ -1,2 +1,2 @@ | |||
class ManageIQ::Providers::EmbeddedAutomationManager::ConfigurationWorkflow < ManageIQ::Providers::AutomationManager::ConfigurationWorkflow | |||
class ManageIQ::Providers::EmbeddedAutomationManager::ConfigurationWorkflow < ManageIQ::Providers::AutomationManager::ConfigurationScript |
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.
@jameswnl please remove all ConfigurationWorkflow
classes from EmbeddedAutomationManager
and EmbeddedAnsibleManger
. We currently don't support them.
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.
yes, in progress. removing this causing the spec to fail. Because embedded/external share the same set of specs and vcr cassettes.
The vcr part is troublesome because of the allow_unused_http_interactions => false
and embedded spec won't retrieve the workflows
causing unused HTTP error. Any suggestion?
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.
Shall we keep this in place? As far as UI/Automate are not using them, no material effects (For embedded one, user cannot create a workflow anyway).
Otherwise, we'll have to split the specs and 95% of the specs would have to be duplicated code.
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'm fine with keeping it since it won't be used anyway.
Checked commits jameswnl/manageiq@50a7589~...0262a2d with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
@miq-bot add_labels providers/ansible_tower, refactor |
@miq-bot remove_label wip |
@jameswnl Cannot apply the following label because they are not recognized: refactor |
@@ -26,6 +26,8 @@ class ManageIQ::Providers::EmbeddedAnsible::AutomationManager < ManageIQ::Provid | |||
require_nested :Refresher | |||
require_nested :RefreshWorker | |||
|
|||
has_many :configuration_workflows, :dependent => :destroy, :foreign_key => "manager_id", :inverse_of => :manager |
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.
Is this needed?
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.
Without this, a bunch specs will fail due to the Inventory collection logic. I can work on a separate PR just to remove 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.
Right now, the persistor and parser are shared between Embedded and Tower. So not doing this, we will need to add a bunch of conditions to differentiate the 2, or partially separate them. So adding this is actually nicer :-)
So I am fine with Embedded responding to .configuration_workflows, but never refreshing it. (performance wise, this will be recognized as noop in embedded refresh and skipped fast)
Merged, but I have a concern about refresh, even with the configuration_workflows association. We need to verify that we don't create and delete configuration_scripts over and over on refresh. Easiest way is to verify the ids are the same before and after. |
Reverted some of the changes that were made to use ManageIQ/manageiq#17580 and adjusted code to use subclass in ManageIQ/manageiq#17720 Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1590441 Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1468339
As a alternative implementation in terms of relationship between
automation_manager
andconfiguration_script
to #17659The related change in external tower repo ManageIQ/manageiq-providers-ansible_tower#112
@blomquisg @Fryguy @bzwei @gmcculloug