Bug 790664 - [RFE] Template configuration mismatch in aeolus, displays c1.xlarge instead of m1.large
Summary: [RFE] Template configuration mismatch in aeolus, displays c1.xlarge instead o...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
Assignee: Angus Thomas
QA Contact: wes hayutin
URL:
Whiteboard:
: 801505 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-15 06:17 UTC by Rehana
Modified: 2012-03-09 15:52 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-17 14:11:34 UTC
Embargoed:


Attachments (Terms of Use)
Template mismatch (216.30 KB, image/png)
2012-02-15 06:17 UTC, Rehana
no flags Details

Description Rehana 2012-02-15 06:17:27 UTC
Created attachment 562130 [details]
Template mismatch

Steps to Reproduce:

1. Create a hardware profile with below configuration
    memory(MB)      1024
    cpu count       2
    storage(GB)     200
    architecture
    label     x86_64
     
Expected Results:

The close match from aws template definition for the above configuration is m1.large.
     
Actual Results:
    Aeolus displays c1.xlarge as the close match(PFA: Template mismatch.png)
     
Additional info:
    cost of m1.large:$0.20 per hour(for Linux usage)
    cost of c1.xlarge:$0.40 per hour(for Linux usage)
     
Conclusion:

    It seems that aeolus is choosing the close match based on RAM value.  It will be really appreciated, if aeolus would consider all the possible parameters (which includes the cost also) to choose the best possible match, this will benefit the end customer to a greater extent.

Comment 1 wes hayutin 2012-02-17 14:11:34 UTC
Contact me.. Thanks

Comment 2 Scott Seago 2012-02-29 22:18:29 UTC
The problem is that cost isn't available via deltacloud. All we have is RAM and CPU. Taking both RAM and CPU into account would potentially better than simply taking RAM into account, but that would require us to define the relative "size" of a given amount of extra RAM vs. a given amount of extra CPU, and so far we hadn't come up with a satisfactory way of doing this.

Comment 3 wes hayutin 2012-03-09 15:52:30 UTC
*** Bug 801505 has been marked as a duplicate of this bug. ***


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