Bug 1300767 - Deleted container provider leaves orphaned subordinate resources
Summary: Deleted container provider leaves orphaned subordinate resources
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: GA
: 5.6.0
Assignee: Mooli Tayer
QA Contact: Tony
URL:
Whiteboard: container
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-21 16:37 UTC by ncatling
Modified: 2016-10-13 14:50 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-15 14:09:22 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description ncatling 2016-01-21 16:37:35 UTC
Description of problem:
Deleted OSE provider leaves orphaned subordinate resources, specifically:
Projects, Routes, Container Services, Replicators, Pods, Containers, Nodes, Images and Registries.


Version-Release number of selected component (if applicable):
CFME 5.5.0


How reproducible:
Removed OSE provider from VMDB. Subordinate resources remain.

Steps to Reproduce:
1. Remove container provider from VMDB
2. Wait for job to complete
3. Review subordinate resources, Projects for example. Deleted provider's Projects remain in the VMDB.

Actual results:
Container provider's orphaned subordinate resources remain in VMDB, specifically: Projects, Routes, Container Services, Replicators, Pods, Containers, Nodes, Images and Registries.

Expected results:
All subordinate resources should be deleted along with parent provider.

Additional info:

Comment 1 Federico Simoncelli 2016-01-21 17:29:38 UTC
If I recall correctly removal of entities is deferred/collected at a later time (after the provider is deleted). Greg Blomquist for sure knows how this part is supposed to work.

Mooli can you sync with Greg and check if we're missing this cleanup? Thanks!

Comment 3 Mooli Tayer 2016-01-25 16:36:17 UTC
This does not reproduce on master. 

I will test on the reported tag (CFME 5.5.0) tomorrow and see how to proceed.

Comment 6 Mooli Tayer 2016-02-14 16:35:00 UTC
I can not get a reproduction of this on any environment.

Nick: could you post logs please? specifically we should see a "Record delete initiated" at first and "Removed EMS [<name>] id [<id>]" at the end.
If there is some error we should see a "<name>: Error during destroy:..." msg
(grepping the ems_name should suffice).

the destroy call is enqueued and right after that we should see the 'Removed':

[----] I, [2016-02-14T17:38:49.551490 #24071:7ad988]  INFO -- : MIQ(MiqGenericWorker::Runner#get_message_via_drb) Message id: [54], MiqWorker id: [2], Zone: [default], Role: [], Server: [], Ident: [generic], Tar
get id: [], Instance id: [1], Task id: [], Command: [ManageIQ::Providers::ContainerManager.destroy], Timeout: [3600], Priority: [100], State: [dequeue], Deliver On: [], Data: [], Args: [], Dequeued in: [6.454513
205] seconds
[----] I, [2016-02-14T17:38:49.551561 #24071:7ad988]  INFO -- : MIQ(MiqQueue#deliver) Message id: [54], Delivering...
[----] I, [2016-02-14T17:38:50.182974 #24071:7ad988]  INFO -- : MIQ(ExtManagementSystem.after_destroy) Removed EMS [erez] id [1]

Lets continue to debug together if there is nothing interesting in the logs.

There is a possibility that the bug is in the refresh: example: after a refresh
a container_service is added with out an ems_id. Then it will not deleted. Can you maybe reproduce something like that  

Note, relevant code around:
ExtManagementSystem.after_destroy and EmsCommon: if task == "destroy"

Comment 7 ncatling 2016-03-15 14:08:02 UTC
Hi Mooli, I'm not able to reproduce this. I have since upgraded my environment to 552, perhaps that has resolved the problem. I'll close as not a bug.


Note You need to log in before you can comment on or make changes to this bug.