Bug 796725

Summary:	Check images are actually available immediately before attempting to launch
Product:	[Retired] CloudForms Cloud Engine	Reporter:	Angus Thomas <athomas>
Component:	aeolus-conductor	Assignee:	Jan Provaznik <jprovazn>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Giulio Fidente <gfidente>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	1.0.0	CC:	akarol, cpelland, deltacloud-maint, gfidente, hbrock, jguiditt, ssachdev, whayutin
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	aeolus-conductor-0.13.21-1.el6cf	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-13 19:48:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Angus Thomas 2012-02-23 15:04:10 UTC

As described in this comment: https://bugzilla.redhat.com/show_bug.cgi?id=794496#c6

I would suggest to Conductor guys to perform a check before they are launching
instance via DC to verify that the image they want to use is ready and
correctly reported by Deltacloud:

GET /api/images/:image_id

Aso the image resource in DC reports 'status' which should say if the image is
*ready* for the launch (<status>OK</status>). 

So instead of just trying to launch an instance and report to user that the
instance launch failed, we should report to user that the image user wants to
launch is not available due to whatever error and IF log inspection is needed
to figure out reason.

Comment 1 Hugh Brock 2012-02-27 18:29:19 UTC

*** Bug 797955 has been marked as a duplicate of this bug. ***

Comment 2 Jason Guiditta 2012-02-28 20:55:10 UTC

Tzumainn discussed this issue with several of us on the dev team, and we feel this is not the direction we should be going, especially in a bug fix phase.  This seems to be very similar to what was requested in 
https://bugzilla.redhat.com/show_bug.cgi?id=788239, which we decided was behaving correctly by giving the user valid feedback from delta cloud showing why the requested action could not be performed.  This i snot some meaningless stack trace, but a use bit of information the user can act on.  Putting in all kinds of launch/pre-action conditions is, in my opinion, a slippery slope, and unlikely to ever catch all possible conditions (and possibly end up checking things not all users want).  I think we would be ether served by allowing (and this is more in general) validity to be determined and explained at the time the action is attempted, rather than hiding it behind a complex rules engine.

Comment 3 Angus Thomas 2012-03-06 17:28:45 UTC

The solution here, which is not in scope for the 1.0 release, is for conductor to support retrying, including switching to an alternative realm/provider account, when a launch invocation fails. We also, potentially, need amendments to the deltacloud API to enable better reporting of root causes of launch failures.

Comment 4 Jan Provaznik 2012-09-03 15:10:52 UTC

Currently if the image is not found, deployment rollback is done and Conductor tries to launch whole deployment with next possible configuration (different hw profile, provider account, realm...).

We can optimize launch retry to choose completely different provider in next try when the image is not found in future,  also dc-api error categorization is needed for this.

Comment 5 Giulio Fidente 2012-10-25 10:13:58 UTC

works as per comment #4 using aeolus-conductor-0.13.21-1.el6cf