Bug 790664

Summary: [RFE] Template configuration mismatch in aeolus, displays c1.xlarge instead of m1.large
Product: [Retired] CloudForms Cloud Engine Reporter: Rehana <redakkan>
Component: aeolus-conductorAssignee: Angus Thomas <athomas>
Status: CLOSED NOTABUG QA Contact: wes hayutin <whayutin>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, deltacloud-maint, ftaylor, rananda, ssachdev, sseago
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-17 14:11:34 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
Template mismatch none

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. ***