Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 855778

Summary: The Deployment could not be deleted: Attempted to update a stale object: Instance
Product: [Retired] CloudForms Cloud Engine Reporter: Tomas Hrcka <thrcka>
Component: aeolus-conductorAssignee: Jan Provaznik <jprovazn>
Status: CLOSED CANTFIX QA Contact: Rehana <aeolus-qa-list>
Severity: medium Docs Contact:
Priority: urgent    
Version: 1.1.0CC: jprovazn, morazi
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-13 12:37:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
destroy deployment from rails console
none
back trace none

Description Tomas Hrcka 2012-09-10 09:22:04 UTC
Created attachment 611364 [details]
destroy deployment from rails console

Description of problem:


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


How reproducible:


Steps to Reproduce:
1. Create multi instance deployment on RHEVM
2. start the deployment
3. stop the deployment
4. try to delete it
  
Actual results:
flash message: The Deployment *** could not be deleted: Attempted to update a stale object: Instance


Expected results:

delete the deployment

Additional info: 

the logs are clear but when you try destroy deployment from rails console you will get attached trace.

Comment 2 Tomas Hrcka 2012-09-10 10:36:11 UTC
Created attachment 611392 [details]
back trace

Comment 3 Jan Provaznik 2012-09-19 13:09:47 UTC
The problem is that we have really old version of deltacloud-core in RHEL, this version has a bug - it returns state 'pending' instead of 'shutting_down' when an instance is being stopped. Pending state should be used only when an instance is being started.

And conductor compares last pending/running times to distinguish if an instance is in stopped state after creation or if it was already running before.

There are 2 options how to fix this:
1) update deltacloud-core in RHEL
2) if 1) is not possible, create some quickfix on conductor side so that conductor will not use pending time to check if an instance needs to be started.

Comment 4 Jan Provaznik 2012-09-19 13:14:25 UTC
the dc-core issue was tracked here: https://issues.apache.org/jira/browse/DTACLOUD-148

Comment 5 Jan Provaznik 2012-09-19 13:40:20 UTC
Ouch, sorry, I commented wrong BZ :). Ignore both comments above, they are related to https://bugzilla.redhat.com/show_bug.cgi?id=857542

Comment 6 Jan Provaznik 2012-09-21 07:47:37 UTC
the stale error can be fixed easily by doing 'self.reload' inside app/models/instance.rb#destroy_on_provider. do_action method in taskomatic updates instance object if an exception is raised.

The problem is that this reveals more serious problem - taskomatic catches all exceptions when doing some instance action (start/stop/reboot) and this exception is not reraised, it ust sets last_error attribute for the instance. We don't check in rest of code if the operation was successful and just blindly expect it was. 

So to fix this properly we should always check if the taskomatic 'do_action' call was successful or not. Fix for this might be more invasive so 2.0.0 flags looks good (unless it turns out that this exception is raised often).