Retired VM not being deleted from provider

[agrare]

It has been observed that VMs which were provisioned by ManageIQ occasionally are not deleted from the underlying provider, but rather are left powered off and left "orphaned" rather than "archived".

It appears that when we started to purge MiqRequest records after 6 months (#21577), that caused the MiqRequest records associated with those requests to be destroyed [ref]

The vm.miq_provision object is used by the retirement state machine to determine if the VM should be removed from disk [ref].

The result, if a VM is retired >6 months after it was provisioned then it is left powered off on the provider rather than deleted from disk.

This was initially released with spassky-1 so it is a relatively new problem.

[Fryguy]

Sounds to me like we need to change the MiqRequest purging to consider requests tied to live services/VMs as being active, and only purge inactive requests.

[agrare]

Yes exactly my thoughts, there should be a destination_id on the associated miq_request_task

[jrafanie]

Yes exactly my thoughts, there should be a destination_id on the associated miq_request_task

Would this be relevant for only MiqProvisionTask or all request task subclasses?

miq_request_tasks can have many miq_request_tasks so it would need to walk the descendants to find any task with a destination that's a particular state... Do we need to check for existence of a destination object or as long as it's not archived? What about not retired? What about services or other things that aren't vms/templates?

manageiq/app/models/miq_request.rb

Lines 13 to 20 in 808eded

	belongs_to :source, :polymorphic => true
	belongs_to :destination, :polymorphic => true
	belongs_to :requester, :class_name => "User"
	belongs_to :tenant
	belongs_to :service_order
	belongs_to :parent, :class_name => "MiqRequest"
	has_many :miq_approvals, :dependent => :destroy
	has_many :miq_request_tasks, :dependent => :destroy

Do we care about destination on the request itself? What about source, service_order, parent request?

[agrare]

Yeah the query could get a little nasty.

I was originally thinking we could use some other way to determine if we provisioned the VM for purposes of retirement (delete vs power-off), but upstream user said they use the options from the miq_provision object for other purposes.

during vm provision we store options in the miq_provision object and use those options once the vm gets deleted again

If there isn't any information in the miq_request itself we could dependent nullify the relationship and have an independent purger for the miq_request_tasks.

[jrafanie]

I was originally thinking we could use some other way to determine if we provisioned the VM for purposes of retirement (delete vs power-off), but upstream user said they use the options from the miq_provision object for other purposes.

during vm provision we store options in the miq_provision object and use those options once the vm gets deleted again

So, I guess the question is should we store retirement information in a object that isn't the provision object? Vm custom attributes or something? Is keeping the provision object around for this type of information worth it? Is there anything else that's relevant about the provision object?

What's the expectation of the provision object if the vm / service / thing is very long lived? Do they just remain permanently?

Should requests remain forever until their associated objects are no longer live?

I think we still need miq request classes and subclasses to validate their relationships are "live" and the purger should use this mechanism to only delete things that are truly gone.

[agrare]

Should requests remain forever until their associated objects are no longer live?

They used to just remain forever full stop 😆 I think the provision request should remain while the VM is active. Like I said I don't know what information is in the request itself that might be helpful I need to review that.