When is it safe to delete a generic object?


#1

If I add a VM to a service, and then remove the VM from VMDB, it disappears from the service as well:

s1 = $evm.vmdb(:service).find_by_name("s1")
puts s1.vms.count
0
vm = $evm.vmdb(:vm).find_by_name("vm1")
vm.add_to_service(s1)
puts s1.vms.count
1
vm.remove_from_vmdb
puts s1.vms.count
0

If I do the same with generic objects, it is not removed from the service:

s1 = $evm.vmdb(:service).find_by_name("s1")
puts s1.generic_objects.count
0
go1 = $evm.vmdb(:generic_object).find_by_name("go1")
go1.add_to_service(s1)
puts s1.generic_objects.count
1
go1.remove_from_vmdb
puts s1.generic_objects.count
1
puts s1.generic_objects.to_s
[nil]

So the object is still referenced in the service, but with nil. The UI still shows 1 generic object of the service and if I try to click the objects I get the following error message:

go_nonexistent

In order to avoid this problem I found a workaround to remove it from the service before removing from vmdb:

go1.remove_from_service(s1)
go1.remove_from_vmdb

But I need to keep track which service(s) the object were added to safely delete it. Is this behavior intended or an issue?


#2

This is a bug, that was already fixed, but has not landed in Cloudforms yet.

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



#3

thanks @buc


#4

If your service is an Embedded Ansible type of service, then you can call a retirement playbook to clean up any generic objects owned by the service. Here is an example: https://manageiq.gitbook.io/mastering-cloudforms-automation-addendum/generic_objects/chapter#deleting-generic-objects

pemcg


#5

I’m using automation scripts (started from buttons) to create / delete the objects. I adapted PR17679 Thomas sent me until it arrives in the next release:

$evm.vmdb(:service_resource).where("resource_id = #{go1.id}").each do |sr|
  go1.remove_from_service(sr.service)
end