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

Provider to orchestrate_destroy managers first - Alt #16755

Merged
merged 1 commit into from
Jan 17, 2018

Conversation

jameswnl
Copy link
Contributor

@jameswnl jameswnl commented Jan 5, 2018

https://bugzilla.redhat.com/show_bug.cgi?id=1491704
https://bugzilla.redhat.com/show_bug.cgi?id=1510179

Destroying Ansible Tower Provider and Foreman Provider is being rolled back because the associated manager is being held up by workers (introduced by #14675)

Following this gist

Other required PRs:

A related nice-to-have PR: #16798 (Taking this out)

@blomquisg
Copy link
Member

@jameswnl
Copy link
Contributor Author

@miq-bot add_labels providers, bug, blocker

@jameswnl
Copy link
Contributor Author

@miq-bot add_lables gaprindashvili/yes

@miq-bot
Copy link
Member

miq-bot commented Jan 11, 2018

@jameswnl unrecognized command 'add_lables', ignoring...

Accepted commands are: add_label, assign, close_issue, move_issue, remove_label, rm_label, set_milestone

@jameswnl
Copy link
Contributor Author

@miq-bot add_labels gaprindashvili/yes

@jameswnl
Copy link
Contributor Author

@Fryguy @blomquisg @bdunne please review.

thanks

@@ -36,7 +36,6 @@ def self.should_define_delete_queue_class_method
def self.should_queue_destroy_on_instance(queue_method = "destroy")
it "should queue up destroy on instance" do
cond = ["class_name = ? AND instance_id = ? AND method_name = ?", @obj.class.name, @obj.id, queue_method]

Copy link
Member

Choose a reason for hiding this comment

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

Why did this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

unintended

Copy link
Member

Choose a reason for hiding this comment

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

Would you mind removing it from the PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i did!, but it keeps coming back 👿

@@ -439,22 +440,17 @@

deliver_queue_message

expect(MiqQueue.count).to eq(1)
expect(MiqQueue.last.deliver_on).to_not be_nil
expect(MiqQueue.count).to eq(0)
Copy link
Member

Choose a reason for hiding this comment

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

I think you need to update the description of this test since the functionality has changed.


deliver_queue_message

expect(MiqQueue.count).to eq(0)
Copy link
Member

Choose a reason for hiding this comment

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

I think this test can be merged with the one above since they are effectively testing the same thing now.

@@ -466,8 +462,8 @@
it "queues up destroy for child_managers" do
described_class.destroy_queue(ems.id)

expect(MiqQueue.count).to eq(2)
expect(MiqQueue.pluck(:instance_id)).to include(ems.id, child_manager.id)
expect(MiqQueue.count).to eq(1)
Copy link
Member

Choose a reason for hiding this comment

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

Again, the description needs to be updated since the child manager destroy is no longer queued.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now I've done some re-arrangement of the specs

provider.destroy(task.id)
task.reload
expect(task).to have_attributes(
'state' => MiqTask::STATE_FINISHED,
Copy link
Member

Choose a reason for hiding this comment

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

Why string keys here and symbols above?

@@ -1,5 +1,5 @@
describe Provider do
let(:provider) { described_class.new }
let(:provider) { FactoryGirl.create(:provider) }
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this should have changed for the rest of the tests when only the two new ones require a record be persisted to the database. The remaining tests will be slowed down unnecessarily.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

got them separately handled

@@ -6,7 +6,7 @@ class ManageIQ::Providers::EmbeddedAnsible::Provider < ::Provider
has_one :automation_manager,
:foreign_key => "provider_id",
:class_name => "ManageIQ::Providers::EmbeddedAnsible::AutomationManager",
:dependent => :destroy,
:dependent => :destroy, # to be removed after ansible_tower side code is updated
Copy link
Member

Choose a reason for hiding this comment

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

Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's now being explicitly called in provider.destroy

@jameswnl jameswnl force-pushed the orch-destroy2 branch 4 times, most recently from d0a8511 to ca808e9 Compare January 16, 2018 14:01
ids.each do |id|
MiqQueue.put(
def self._queue_task(task, ids, task_id = nil)
Array.wrap(ids).each do |id|
Copy link
Member

Choose a reason for hiding this comment

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

Why is ids no longer an array?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

to make the other calls lazy like here line 81 and here line 459

Copy link
Member

Choose a reason for hiding this comment

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

hmm... I'm not a fan. But if you're going to do that, can you update the variable name accordingly? Maybe id_or_ids if we have to do this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i am neutral to this. so i changed that to your favor.

@@ -6,7 +6,7 @@ class ManageIQ::Providers::EmbeddedAnsible::Provider < ::Provider
has_one :automation_manager,
:foreign_key => "provider_id",
:class_name => "ManageIQ::Providers::EmbeddedAnsible::AutomationManager",
:dependent => :destroy,
:dependent => :destroy, # to be removed after ansible_tower side code is updated
Copy link
Member

Choose a reason for hiding this comment

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

Why can't this line be removed now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removal of this will break the spec. We'll need ManageIQ/manageiq-providers-ansible_tower#54 (which is in circular dependency with this one).

If we know we'll merge both at the same(near) time, I can do this now.

Copy link
Member

Choose a reason for hiding this comment

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

I assume you meant to link ManageIQ/manageiq-providers-ansible_tower#49 but since that has its own has_one :automation_manager and it's a different subclass of Provider, I don't see how they're related.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

I'm very lost now..

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Offline explained this to Brandon that this has to do with an existing bug in the shared Tower spec (linked in my last comment)


_log.info(msg)
task = MiqTask.create(
:name => "Destroying #{self.class.name} with id: #{id}",
Copy link
Member

Choose a reason for hiding this comment

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

Why not reuse msg since it's the same string?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

end

def destroy_queue
msg = "Destroying #{self.class.name} with id: #{id}"
Copy link
Member

Choose a reason for hiding this comment

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

Please spell it out

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You mean hard code the class name of current provider? It would then always be the base class, right?

Copy link
Member

Choose a reason for hiding this comment

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

No, "message"

@@ -36,7 +36,6 @@ def self.should_define_delete_queue_class_method
def self.should_queue_destroy_on_instance(queue_method = "destroy")
it "should queue up destroy on instance" do
cond = ["class_name = ? AND instance_id = ? AND method_name = ?", @obj.class.name, @obj.id, queue_method]

Copy link
Member

Choose a reason for hiding this comment

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

Would you mind removing it from the PR?


expect(MiqQueue.count).to eq(1)
expect(MiqQueue.count).to eq(2)
expect(MiqQueue.pluck(:instance_id)).to include(ems.id, ems2.id)
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this be match_array? I wouldn't expect any other instance_ids to be on the queue.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

right!

context "#destroy_queue" do
let(:server) { EvmSpecHelper.local_miq_server }
let(:zone) { server.zone }
let(:ems) { FactoryGirl.create(:ext_management_system, :zone => zone) }
Copy link
Member

Choose a reason for hiding this comment

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

Sort alphabetically please

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍


deliver_queue_message
task = MiqTask.find(task_id)
Copy link
Member

Choose a reason for hiding this comment

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

This can be consolidated to a single expectation:

expect(MiqTask.find(task_id)).to have_attributes(
  :state => "Finished",
  :status => "Ok",
)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

deliver_queue_message

expect(MiqQueue.count).to eq(0)
expect(ExtManagementSystem.count).to eq(0)
Copy link
Member

Choose a reason for hiding this comment

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

Do you also need an expectation that the worker is gone?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

expect(task).to have_attributes(
:state => MiqTask::STATE_FINISHED,
:status => MiqTask::STATUS_OK
)
Copy link
Member

Choose a reason for hiding this comment

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

Expect that the manager is gone too?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍

@miq-bot
Copy link
Member

miq-bot commented Jan 16, 2018

Checked commit jameswnl@182b7ba with ruby 2.3.3, rubocop 0.52.0, haml-lint 0.20.0, and yamllint 1.10.0
9 files checked, 0 offenses detected
Everything looks fine. ⭐

@blomquisg
Copy link
Member

@bdunne can you re-review based on @jameswnl updates

@bdunne bdunne merged commit ef04837 into ManageIQ:master Jan 17, 2018
@bdunne bdunne added this to the Sprint 78 Ending Jan 29, 2018 milestone Jan 17, 2018
@bdunne bdunne self-assigned this Jan 17, 2018
simaishi pushed a commit that referenced this pull request Jan 18, 2018
@simaishi
Copy link
Contributor

Gaprindashvili backport details:

$ git log -1
commit 70ea5cd6b9e38d282e51a2d6ec00baa11b800d6f
Author: Brandon Dunne <brandondunne@hotmail.com>
Date:   Wed Jan 17 15:47:31 2018 -0500

    Merge pull request #16755 from jameswnl/orch-destroy2
    
    Provider to orchestrate_destroy managers first - Alt
    (cherry picked from commit ef04837a999cd942ac9ccf2c6cd6504f5752b6b5)
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1536039
    https://bugzilla.redhat.com/show_bug.cgi?id=1536041

aufi added a commit to aufi/manageiq-providers-openstack that referenced this pull request Jan 23, 2018
Change introduced in ManageIQ/manageiq#16755 is not
compatible with OSP provider which uses cascade deletion of related providers.

Nullification introduced in ManageIQ#198
breaks tests and possibly affects Infra provider deletion.

Trying override destroy method with original from AR until we get better solution (preferably in main repo).
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.

5 participants