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

Workflow cloud_tenant fix #19237

Merged

Conversation

kbrock
Copy link
Member

@kbrock kbrock commented Aug 31, 2019

fixes https://bugzilla.redhat.com/show_bug.cgi?id=1746931
Introduced #18353

This did not bring back the type column so all classes were VmOrType.
Since the cloud_tenant method is introduced in a subclass, it was missing.
Now that we are instantiating the correct class (with help from type) all is well.

[----] F, [2019-08-29T09:40:01.670066 #3373:2adf69a8c12c] FATAL -- : Error caught:
[NoMethodError] undefined method `cloud_tenant' for #<VmOrTemplate:0x000055bee25ff310>
Did you mean?  cloud_tenant_id
gems/activemodel-5.1.7/lib/active_model/attribute_methods.rb:432:in `method_missing'
app/models/miq_provision_virt_workflow.rb:1049:in `create_hash_struct_from_vm_or_template'

Copy link
Member

@NickLaMuro NickLaMuro left a comment

Choose a reason for hiding this comment

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

Crap... I guess you called this. Well, if there is a bug then no helping. 👍

@kbrock kbrock added the blocker label Aug 31, 2019
@gmcculloug
Copy link
Member

@kbrock I believe the fix is actually a little different and as you stated in the description it does not make sense that the cloud_tenant_id would be set if the model does not respond to cloud_tenant.

I was thinking that there must be some additional column that is needed for the cloud_tenant relationship to be defined. (And I had previously determined that removing the recently added select call allowed the code to work.

Through a little trail and error I found that adding the type column to the select list fixes the issue. And this all makes sense, as you can see below, that the initial where call returns an OpenStack Template model, but after the select it now contains a base model VmOrTemplate instance for the same VM. (The cloud_tenant association is defined down at the OpenStack sub-classed model.) Finally, adding type back we are able to load the proper sub-class.

irb(main):001:0> vms = VmOrTemplate.where(:id => 3773)
=> #<ActiveRecord::Relation [#<ManageIQ::Providers::Openstack::CloudManager::Template id: 3773, vendor: "openstack"...

irb(main):002:0> vms = vms.select(:id, :name, :guid, :uid_ems, :ems_id, :cloud_tenant_id)
=> #<ActiveRecord::Relation [#<VmOrTemplate id: 3773, name: "HUIS-EvmSnapshot", guid: "6e45d27a-3d57-11e6-ab22-6003089fa294"...

irb(main):003:0> vms.first.cloud_tenant
NoMethodError (undefined method `cloud_tenant' for #<VmOrTemplate:0x00007fe989c36778>)

irb(main):004:0> vms = vms.select(:id, :name, :guid, :uid_ems, :ems_id, :cloud_tenant_id, :type)
=> #<ActiveRecord::Relation [#<ManageIQ::Providers::Openstack::CloudManager::Template id: 3773, name: "HUIS-EvmSnapshot"...

irb(main):005:0> vms.first.cloud_tenant
=> #<ManageIQ::Providers::Openstack::CloudManager::CloudTenant id: 10, name: "admin", description: "admin tenant"...

In the end I think the proper code change is to add :type to the select statement so the sub-class is loaded.

     # Only select the colums we need
-    vms = vms.select(:id, :name, :guid, :uid_ems, :ems_id, :cloud_tenant_id)
+    vms = vms.select(:id, :name, :guid, :uid_ems, :ems_id, :cloud_tenant_id, :type)

@NickLaMuro
Copy link
Member

@gmcculloug oh yeah, that makes so much sense now. Since I was the original author to this mess, I am happy to here that the cloud_tenant_id idea wasn't too far off, and the only real issue was me missing something in the select. Thanks for the great sleuthing!

@kbrock we probably should have a test case for this if possible, but unsure how you would do that.

Copy link
Member

@NickLaMuro NickLaMuro left a comment

Choose a reason for hiding this comment

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

See Greg M's comment

@kbrock kbrock force-pushed the miq_provision_virt_workflow_cloud_tenant branch from b570cc9 to c988392 Compare September 3, 2019 11:45
@miq-bot
Copy link
Member

miq-bot commented Sep 3, 2019

Checked commit kbrock@c988392 with ruby 2.4.6, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0
1 file checked, 0 offenses detected
Everything looks fine. 🍪

Copy link
Member

@gmcculloug gmcculloug left a comment

Choose a reason for hiding this comment

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

Looks good. I would suggest updating the PR description as well.

@kbrock kbrock changed the title Reintroduce workflow respond_to? call Workflow cloud_tenant fix Sep 3, 2019
@jrafanie jrafanie merged commit b598db0 into ManageIQ:master Sep 3, 2019
@jrafanie jrafanie requested review from jrafanie and removed request for tinaafitz September 3, 2019 15:06
@jrafanie jrafanie added this to the Sprint 120 Ending Sep 16, 2019 milestone Sep 3, 2019
@kbrock kbrock deleted the miq_provision_virt_workflow_cloud_tenant branch September 3, 2019 15:08
simaishi pushed a commit that referenced this pull request Sep 3, 2019
@simaishi
Copy link
Contributor

simaishi commented Sep 3, 2019

Ivanchuk backport details:

$ git log -1
commit b8dd448f4e4c08cc0798fc20c7ea78ce608686e7
Author: Joe Rafaniello <jrafanie@users.noreply.github.com>
Date:   Tue Sep 3 11:06:20 2019 -0400

    Merge pull request #19237 from kbrock/miq_provision_virt_workflow_cloud_tenant
    
    Workflow cloud_tenant fix
    
    (cherry picked from commit b598db0dec6fbbe8fdaa4554fac193f7d6e0d3be)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1746931

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.

6 participants