Bug 794505

Summary: update configure script to add a lower cost hwp for ec2
Product: [Retired] CloudForms Cloud Engine Reporter: wes hayutin <whayutin>
Component: aeolus-configureAssignee: Maros Zatko <mzatko>
Status: CLOSED ERRATA QA Contact: pushpesh sharma <psharma>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.0.0CC: akarol, bbandari, ckannan, deltacloud-maint, hbrock, morazi, mzatko, psharma, ssachdev, sseago
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-15 20:45:54 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
verified_screenshot none

Description wes hayutin 2012-02-16 23:41:53 UTC
Description of problem:

Right now we are creating a default hwp profile w/ minimum specs


Name	 Unit	 Minimum Value
memory	 MB	 512
cpu	 count	 1
storage	 GB	 n/a
architecture	 label	 x86_64


However in ec2 the closet match for 512mb of ram and x86_64 is
http://aws.amazon.com/ec2/instance-types/

The key here is to match on the memory.. and remember t1.micro is not supported

High-CPU Extra Large Instance

7 GB of memory
20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each)
1690 GB of instance storage
64-bit platform
I/O Performance: High
API name: c1.xlarge

CRAZY RIGHT.. but true.. 
**************************************

512 mb and x86_64 is great for rhevm, and vsphere....
I'm suggesting that we add another default hardware profile that matches a cheaper profile in ec2.

The lowest cost option for ec2 x86_64 is
Large Instance

7.5 GB memory
4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each)
850 GB instance storage
64-bit platform
I/O Performance: High
API name: m1.large


This will help reduce ec2 dev/qe costs 

Thanks

Comment 1 Mike Orazi 2012-02-27 17:05:30 UTC
This should have a 'generic' name like small/tiny/micro so that it does not appear specific to ec2.

Comment 2 Maros Zatko 2012-02-29 16:48:50 UTC
There is a suggestion to have 2 hwps; one for tiny and one other.
Please provide some clarification on what hwps we want and how should be called/named.

thanks

Comment 3 Scott Seago 2012-02-29 19:30:20 UTC
Really there aren't many options.

The current HWP already finds the "smallest" x86_64 ec2 HWP, and we don't support micro.

I would suggest something designed to match m1.small -- something like 1 GB RAM, 1 CPU, storage blank, and arch=i386

Just call it i386 or something to indicate that it's a 32  bit HWP -- Mike -- does that seem OK to you?

Comment 5 Maros Zatko 2012-03-07 14:35:13 UTC
in master

commit b7e485eaf8d5815ac6f60f1a33cd76142ac49154
Author: Maros Zatko <mzatko>
Date:   Mon Mar 5 15:06:17 2012 +0100

    BZ 794505: lower cost hwp for ec2
    
    https://bugzilla.redhat.com/show_bug.cgi?id=794505
    
    * 'hwp1' was matching an expensive xlarge instance
    * changed 'hwp1' to match 'm1.large - x86_64, 7680 ram, 850gb, 4cpu'
    * added 'small' profile '500mb, 1cpu, blank gb, i386'
      which matches 'm1.large - i386, 1.7gb ram, 160gb, 1cpu'

Comment 7 pushpesh sharma 2012-04-17 07:13:54 UTC
A small HWP is added at the time of configure,that closely ,matches with ec2-m1-small HWP. 

Marking this as verified as this profile suits the need to bring down the bills of ec2.

[root@dhcp201-169 ~]# rpm -qa|grep aeolus
aeolus-configure-2.5.2-1.el6.noarch
aeolus-conductor-0.8.7-1.el6.noarch
rubygem-aeolus-cli-0.3.1-1.el6.noarch
aeolus-conductor-doc-0.8.7-1.el6.noarch
aeolus-all-0.8.7-1.el6.noarch
aeolus-conductor-daemons-0.8.7-1.el6.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch

See attached screen shot for details.

Comment 8 pushpesh sharma 2012-04-17 07:14:45 UTC
Created attachment 577924 [details]
verified_screenshot

Comment 9 errata-xmlrpc 2012-05-15 20:45:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-0586.html