Bug 1798047 - Azure subnets are kept in CFME even after removing Azure provider
Summary: Azure subnets are kept in CFME even after removing Azure provider
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.11.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: GA
: 5.12.0
Assignee: Adam Grare
QA Contact: Sudhir Mallamprabhakara
Red Hat CloudForms Documentation
URL:
Whiteboard: cloud:provider:azure:network:subnets
Depends On:
Blocks: 1805843
TreeView+ depends on / blocked
 
Reported: 2020-02-04 13:26 UTC by Matouš Mojžíš
Modified: 2020-10-26 16:03 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1805843 (view as bug list)
Environment:
Last Closed: 2020-10-26 16:03:41 UTC
Category: Bug
Cloudforms Team: Azure
Target Upstream Version:
Embargoed:
mfeifer: mirror+


Attachments (Terms of Use)
azure provider subnets are in cfme even after deleting of provider (39.51 KB, image/png)
2020-02-04 13:26 UTC, Matouš Mojžíš
no flags Details

Description Matouš Mojžíš 2020-02-04 13:26:38 UTC
Created attachment 1657549 [details]
azure provider subnets are in cfme even after deleting of provider

Description of problem:


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

How reproducible:
Always

Steps to Reproduce:
1. Add Azure Provider
2. Delete Azure provider
3. Wait some time until Azure provider is deleted

Actual results:


Expected results:


Additional info:

Comment 4 Adam Grare 2020-02-04 13:45:16 UTC
It definitely looks like the dependent relation didn't cascade destroy the cloud_subnets:

irb(main):004:0> ManageIQ::Providers::Azure::NetworkManager::CloudSubnet.first
=> #<ManageIQ::Providers::Azure::NetworkManager::CloudSubnet id: 1135, name: "default", ems_ref: "/subscriptions/9ee63d8e-aee7-4121-861c-d67a5b8d231...", ems_id: 224, availability_zone_id: 139, cloud_network_id: 1124, cidr: "10.5.0.0/24", status: nil, dhcp_enabled: nil, gateway: nil, network_protocol: nil, cloud_tenant_id: nil, dns_nameservers: nil, ipv6_router_advertisement_mode: nil, ipv6_address_mode: nil, extra_attributes: nil, type: "ManageIQ::Providers::Azure::NetworkManager::CloudS...", network_router_id: nil, network_group_id: nil, parent_cloud_subnet_id: nil>
irb(main):005:0> ManageIQ::Providers::Azure::NetworkManager::CloudSubnet.first.ems_id
=> 224
irb(main):006:0> ManageIQ::Providers::Azure::NetworkManager::CloudSubnet.first.ext_management_system
=> nil

There are also some FloatingIps left over:
irb(main):007:0> ManageIQ::Providers::Azure::NetworkManager::FloatingIp.count
=> 1
irb(main):008:0> ManageIQ::Providers::Azure::NetworkManager::FloatingIp.first
=> #<ManageIQ::Providers::Azure::NetworkManager::FloatingIp id: 299, type: "ManageIQ::Providers::Azure::NetworkManager::Floati...", ems_ref: "/subscriptions/9ee63d8e-aee7-4121-861c-d67a5b8d231...", address: "LB-CFME-PIP", ems_id: 224, vm_id: nil, cloud_network_only: nil, cloud_tenant_id: nil, network_port_id: 2009, cloud_network_id: nil, fixed_ip_address: nil, status: "Succeeded", network_router_id: nil>
irb(main):009:0> ManageIQ::Providers::Azure::NetworkManager::FloatingIp.first.ext_management_system
=> nil

Comment 5 Adam Grare 2020-02-04 14:29:23 UTC
The destroy looks like it was successful

[----] I, [2020-01-31T13:04:41.576009 #1110:2ac0bace65bc]  INFO -- : MIQ(ManageIQ::Providers::Azure::CloudManager#disable!) Disabling EMS [azure_msdn] id [223].
[----] I, [2020-01-31T13:04:41.585622 #1110:2ac0bace65bc]  INFO -- : MIQ(ManageIQ::Providers::Azure::NetworkManager#pause!) Pausing EMS [azure_msdn Network Manager] id [224].
[----] I, [2020-01-31T13:04:41.597973 #1110:2ac0bace65bc]  INFO -- : MIQ(ManageIQ::Providers::Azure::NetworkManager#pause!) Pausing EMS [azure_msdn Network Manager] id [224] successful.
[----] I, [2020-01-31T13:04:41.600277 #1110:2ac0bace65bc]  INFO -- : MIQ(ManageIQ::Providers::Azure::CloudManager#disable!) Disabling EMS [azure_msdn] id [223] successful.
[----] I, [2020-01-31T13:04:41.601449 #1110:2ac0bace65bc]  INFO -- : MIQ(ManageIQ::Providers::Azure::CloudManager#destroy) Destroying 1 child_managers
[----] I, [2020-01-31T13:04:41.602648 #1110:2ac0bace65bc]  INFO -- : MIQ(ManageIQ::Providers::Azure::NetworkManager#destroy) Destroying 0 child_managers
[----] I, [2020-01-31T13:04:41.768081 #1110:2ac0bace65bc]  INFO -- : MIQ(ExtManagementSystem.after_destroy) Removed EMS [azure_msdn Network Manager] id [224]

But at the same time a refresh for the network manager was running
[----] I, [2020-01-31T13:04:41.775442 #1522:2ac0bace65bc]  INFO -- : Exception in realtime_block :ems_refresh - Timings: {:collect_inventory_for_targets=>14.271465539932251, :parse_targeted_inventory=>2.745025873184204, :save_inventory=>0.25409436225891113, :ems_refresh=>17.270833492279053}
[----] E, [2020-01-31T13:04:41.775712 #1522:2ac0bace65bc] ERROR -- : MIQ(ManageIQ::Providers::Azure::NetworkManager::Refresher#refresh) EMS: [azure_msdn Network Manager], id: [224] Refresh failed
[----] E, [2020-01-31T13:04:41.775834 #1522:2ac0bace65bc] ERROR -- : [ActiveRecord::RecordNotFound]: Couldn't find ManageIQ::Providers::Azure::NetworkManager with 'id'=224 [WHERE "ext_management_systems"."type" IN ('ManageIQ::Providers::Azure::NetworkManager')]  Method:[block (2 levels) in <class:LogProxy>]
[----] E, [2020-01-31T13:04:41.775891 #1522:2ac0bace65bc] ERROR -- : /opt/rh/cfme-gemset/gems/activerecord-5.1.7/lib/active_record/relation/finder_methods.rb:343:in `raise_record_not_found_exception!'

Which I'm guessing updated some records after the network_manager destroy completed.

We've had this bug before but it looks like it was only solved for the parent manager, the workers are killed after the child managers are destroyed.  Flipping that order should resolve this.

Comment 7 CFME Bot 2020-02-04 22:56:24 UTC
New commit detected on ManageIQ/manageiq/master:

https://github.com/ManageIQ/manageiq/commit/1ced7e115f78050f65c6c96ffac24ce696d665b9
commit 1ced7e115f78050f65c6c96ffac24ce696d665b9
Author:     Adam Grare <agrare>
AuthorDate: Tue Feb  4 09:31:12 2020 -0500
Commit:     Adam Grare <agrare>
CommitDate: Tue Feb  4 09:31:12 2020 -0500

    Kill workers before destroying child managers

    When destroying an EMS we should kill the workers before destroying the
    child managers to prevent orphan records from being created e.g. by a
    RefreshWorker after the child NetworkManager has been destroyed.

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1798047

 app/models/ext_management_system.rb | 6 +-
 1 file changed, 3 insertions(+), 3 deletions(-)


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