Bug 826130 - Pending (forever) Instances should be allowed to delete
Summary: Pending (forever) Instances should be allowed to delete
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: 1.0.1
Assignee: Jan Provaznik
QA Contact: Shveta
URL:
Whiteboard:
Depends On: 796528
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-29 16:33 UTC by Chris Pelland
Modified: 2018-11-28 20:37 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Faulty instances remained in perpetual “pending” state when launched. Users were unable to delete these instances. This update adds an exception to set faulty instances to “create_failed” status. Users can now delete these instances.
Clone Of: 796528
Environment:
Last Closed: 2012-07-10 07:23:25 UTC
Embargoed:


Attachments (Terms of Use)
Connection_timed_out (212.83 KB, image/png)
2012-06-11 07:56 UTC, Shveta
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:1063 0 normal SHIPPED_LIVE CloudForms Cloud Engine 1.0.1 bug fix update 2012-07-10 11:18:41 UTC

Comment 1 Tzu-Mainn Chen 2012-05-29 17:33:05 UTC
1.0.1 hashes:

commit 13276c749f2b297a5ee3ebdd1af4e5c75e22a72f
BZ 796528 - updated tests
    
    Also removed older test "launch instances if user has no access to hardware profile" which
    doesn't seem to do what it describes anyway.

commit cb9a146f2d29c1f1a80c005a90420fe141249266
BZ 796528 - set CREATE_FAILED status for instances which failed to launch

commit 296b9d2a011462cb1860e2a4e9e0ba1874d7ddfd
 BZ 796528 - instance's config params are now handled from taskomatic
    
    Reason for moving this is that taskomatic's create_instance method automatically
    sets create_failed instance's method when an exception occurs and then reraises
    this exception which is handled in deployment's launch method. add_instance_config!
    method raises an exceptions too and in that case we want to set create_failed state
    too.

commit ed774884c97b7af47491274e1795ed137a3f3f9e
BZ 796528 - deployment launch refactoring
    
    This patch tries to partially cleanup huge deployment launch method,
    the behavior of this method should be unchanged.
    - Instance + InstanceParameter objects creation is moved to separate method
    - common_provider_accounts_for replaced with create_instances_with_params method:
        this method returns only first possible match (and keeps account's priority
        ordering by using ascending_by_priority scope)
    - instance's launch block (including config setup) moved to separate Instance#launch method
    - added :dependent => :destroy for events association, which I think is missing by mistake

Comment 3 Dan Macpherson 2012-06-06 17:06:14 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Faulty instances remained in perpetual “pending” state when launched. Users were unable to delete these instances. This update adds an exception to set faulty instances to “create_failed” status. Users can now delete these instances.

Comment 4 Shveta 2012-06-11 07:56:34 UTC
Created attachment 590838 [details]
Connection_timed_out

Tried to recreate the issue in several ways . 
Could not get an instance in Pending or New state .

Launched an instance with config-server down and it launched the instance in 
create_failed state.

With Rhev , launching the instance with long name also launch a create_failed instance.

Moving the bug to Verified state.

Comment 6 errata-xmlrpc 2012-07-10 07:23:25 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/RHBA-2012-1063.html


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