Bug 773277

Summary: Deployments with stopped instances in it does not get deleted.
Product: [Retired] CloudForms Cloud Engine Reporter: Aziza Karol <akarol>
Component: aeolus-conductorAssignee: Tzu-Mainn Chen <tzumainn>
Status: CLOSED ERRATA QA Contact: Aziza Karol <akarol>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, athomas, deltacloud-maint, hbrock, slinaber, ssachdev
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-15 21:37:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
deployment
none
rails.log
none
deployment_deletion_message none

Description Aziza Karol 2012-01-11 11:51:04 UTC
Description of problem:


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


How reproducible:


Steps to Reproduce:
1.Launch few ec2 deployments.
2.stopped one ec2 deployment.
3.Try deleting the stopped ec2 deployment.
  

UI displays:
The deployment ec3 could not be deleted. see attached screenshot.


Expected results:
deployments with stopped instances should get deleted.


Additional info:
[root@hp-xw6400-01 html]# rpm -qa | grep aeolus
aeolus-conductor-doc-0.8.0-5.el6.noarch
rubygem-aeolus-image-0.3.0-2.el6.noarch
rubygem-aeolus-cli-0.3.0-3.el6.noarch
aeolus-all-0.8.0-5.el6.noarch
aeolus-conductor-0.8.0-5.el6.noarch
aeolus-configure-2.5.0-3.el6.noarch
aeolus-conductor-daemons-0.8.0-5.el6.noarch

Comment 1 Aziza Karol 2012-01-11 11:51:55 UTC
Created attachment 552090 [details]
deployment

Comment 2 wes hayutin 2012-01-11 13:01:23 UTC
Aziza can you recreate and attach deltacloud and rails logs

Comment 3 wes hayutin 2012-01-12 16:35:40 UTC
adding to ce-sprint

Comment 4 wes hayutin 2012-01-12 16:41:55 UTC
removing ce-sprint-next tracker

Comment 5 Aziza Karol 2012-01-18 07:20:25 UTC
deltacloud logs does not display anything while this action is performed.

Attaching rails.log.

Comment 6 Aziza Karol 2012-01-18 07:21:36 UTC
Created attachment 555937 [details]
rails.log

Comment 7 Tzu-Mainn Chen 2012-01-18 21:50:28 UTC
patch submitted:

https://fedorahosted.org/pipermail/aeolus-devel/2012-January/008188.html

Comment 8 Tzu-Mainn Chen 2012-01-20 16:59:59 UTC
Pushed to 1.0-staging:

commit c6bb710493f4afa25e9cb66923f057eec179407c
 BZ 773277 fixed logical operator mistake

Comment 9 Steve Linabery 2012-01-24 15:19:59 UTC
included in aeolus-conductor-0.8.0-10

Comment 10 Aziza Karol 2012-01-25 06:26:02 UTC
Deployments with stopped instances in it gets deleted.

however, the message for ex "The deployments ec2-single and ec2-one were scheduled for deletion"  is displayed after the deployments are deleted.Therefore the deployment deletion process is very slow  and takes lot of time to perform this action.

The scheduled message should be displayed first and then deployments should be deleted.


rpm -qa | grep aeolus
rubygem-aeolus-image-0.3.0-3.el6.noarch
aeolus-conductor-doc-0.8.0-11.el6.noarch
rubygem-aeolus-cli-0.3.0-5.el6.noarch
aeolus-configure-2.5.0-7.el6.noarch
aeolus-conductor-daemons-0.8.0-11.el6.noarch
aeolus-conductor-0.8.0-11.el6.noarch
aeolus-all-0.8.0-11.el6.noarch

Comment 11 Aziza Karol 2012-01-25 06:29:23 UTC
Created attachment 557380 [details]
deployment_deletion_message

Comment 12 Tzu-Mainn Chen 2012-01-25 07:06:03 UTC
Would it be possible to open up a new ticket instead of continuing this one?  I feel like the above is fundamentally different from the intended ticket purpose.

I wasn't sure, but maybe someone on the QA team can verify - are BZs 770555 and 783531 duplicates of this one?

Comment 13 Tzu-Mainn Chen 2012-01-26 23:02:10 UTC
I've been poking around this a bit, a few comments:

a) it doesn't seem like the deletion takes much longer than a few other pages/actions - maybe 5-10 seconds.  Does it take longer for you?

b) the delete action *does* seem to be put into a queue, which means that I don't think we can show the scheduling message any faster.  If we do, it means that we're showing the "queue success" message *before* the actions are actually queued up, which is obviously a risk in case the queue actually fails.

Comment 15 Shveta 2012-01-31 13:13:49 UTC
Stopped instances can be deleted

rpm -qa|grep aeolus
aeolus-conductor-doc-0.8.0-16.el6.noarch
aeolus-configure-2.5.0-11.el6.noarch
aeolus-conductor-daemons-0.8.0-16.el6.noarch
rubygem-aeolus-image-0.3.0-6.el6.noarch
aeolus-all-0.8.0-16.el6.noarch
aeolus-conductor-0.8.0-16.el6.noarch
rubygem-aeolus-cli-0.3.0-7.el6.noarch

Comment 16 errata-xmlrpc 2012-05-15 21:37:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-0583.html