Bug 789498 - Imported ami's are not deployable in regions other than the native region, dont show other providers in deployable page
Summary: Imported ami's are not deployable in regions other than the native region, do...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
Assignee: Angus Thomas
QA Contact: wes hayutin
URL: https://qeblade32.rhq.lab.eng.bos.red...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-10 21:55 UTC by wes hayutin
Modified: 2012-02-27 18:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-27 18:13:53 UTC


Attachments (Terms of Use)
ss (259.78 KB, image/png)
2012-02-10 21:55 UTC, wes hayutin
no flags Details

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 :)


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