Bug 789498

Summary: Imported ami's are not deployable in regions other than the native region, dont show other providers in deployable page
Product: [Retired] CloudForms Cloud Engine Reporter: wes hayutin <whayutin>
Component: aeolus-conductorAssignee: Angus Thomas <athomas>
Status: CLOSED NOTABUG QA Contact: wes hayutin <whayutin>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, deltacloud-maint, matt.wagner, ssachdev
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://qeblade32.rhq.lab.eng.bos.redhat.com/conductor/deployables/1
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-27 18:13:53 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
ss none

Description wes hayutin 2012-02-10 21:55:10 UTC
Created attachment 560996 [details]
ss

Description of problem:

Imported ami's are not deployable in regions other than the native region, dont show other providers in deployable page

Recreate:
1. fill out the provider accounts for us-east and us-west
2. import an ami found in us-east
3. follow the wizard to the deployables page..
4. notice that the status of the import is displayed for regions other us-east

not good.. and confusing...

A user will never be able to push the ami to other regions.. so don't confuse the issue and display it.


The behavior for ec2 I believe is unique.  rhevm and vsphere image *could* technically be pushed to other providers.. so the issue only exists w/ ec2 ami's that are imported.


see screenshot

Comment 1 Matt Wagner 2012-02-14 14:43:20 UTC
I'm not entirely convinced that this needs fixing. You're absolutely right that you can't deploy it in another region, but we're not offering to do that as I assumed on the first read of this. We're showing it as unavailable. It does feel a bit pointless, but it's consistent with what we do on other providers.

My concern here is with adding provider-specific code to what's already a kind of convoluted bit of code for an uncertain gain.

Comment 2 Matt Wagner 2012-02-14 19:05:22 UTC
After speaking a bit with Angus about this, it sounds like this is somewhere between "notabug" and "wontfix" -- per my above comment, this isn't really erroneous behavior, and it would mean different behavior depending on the provider, which I think would be more confusing in the long run.

Comment 3 wes hayutin 2012-02-27 18:13:53 UTC
after speaking w/ Matt, he has convinced me this is not a bug :)