This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 801505 - New Cloud Resource Profile (Hardware) matches wrong instance type in EC2 (c1.xlarge)
New Cloud Resource Profile (Hardware) matches wrong instance type in EC2 (c1....
Status: CLOSED DUPLICATE of bug 790664
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
1.0.0
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Angus Thomas
wes hayutin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-08 12:29 EST by Forrest Taylor
Modified: 2012-05-01 11:41 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-09 10:52:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Forrest Taylor 2012-03-08 12:29:57 EST
When creating a new hardware profile (cloud resource profile), the hardware profile does not match the closest EC2 instance type.  For example, if I enter 512 MB RAM and 1 CPU, using x86_64, it matches the c1.xlarge instance type (7GB RAM, 20 CPU).

Amazon just announced that we can use x86_64 architecture on all instance types (see http://aws.amazon.com/ec2/instance-types/), so a closer match to the parameters above would be the m1.small.

Note, they also announced a new instance type: m1.medium with 3.75GB RAM, 2 CPU and 410 GB storage.

Using 2012-03-01.1 code drop.
Comment 1 Scott Seago 2012-03-08 14:34:30 EST
We have another bugfix that resolves this by moving the default x86_64 profile to 7.5 GB. Right now the matching code finds the smallest-RAM match greater than or equal to the specified profile, which is c1.xlarge for small RAM values. Bumping the RAM to 7.5 GB forces m1.large.

At the moment the new ec2 HWP as announced today is not in scope for 1.0. The code is pushed to the deltacloud repo but at the moment it hasn't been deemed a release blocker. We can't use those new HWPs in conductor until deltacloud has been updated to take advantage of them. That said we should fairly shortly get support for this sort of thing in the upstream codebase to make sure it will all work properly in conductor with the new ec2 HWPs.
Comment 2 Forrest Taylor 2012-03-08 14:58:20 EST
The matching code must also check CPUs at some point, because if I request a CPU count of 25, it matches m2.4xlarge.  It must check memory first.

With pricing in mind, it looks like CPUs would make a better first match, not memory.
Comment 3 Scott Seago 2012-03-08 20:35:00 EST
It checks CPUs for minimum matching specs. The place we _only_ consider memory is if there are more than one matches meeting the minimum.

In other words, memory, CPU, and Storage  are all used to eliminate Hardware Profiles which do not meet minimums. With 25 CPU (minimum), it's got to find something like m2.4xlarge. However, once this is done, of the remaining Hardware Profiles that meet the minimums on all parameters, the one with the lowest memory is chosen. When we put it in place, we realized that Memory alone wasn't ideal. The best approach would be to take cost into account (but we don't have that via API). Barring direct cost, the next best thing would be to estimate cost based on a combination of CPU and RAM, but again it's hard to do that in a cross-cloud way.

It could be that, like you say, we could match CPU first and only consider memory if there were more than one matching profile with an equal number of Virtual CPUs. So, for example, if we had (1 CPU, 10 GB Memory), (2 CPUs, 5 GB Memory), (2 CPUs 10 GB Memory), and the user had asked for at least 1 CPU, 2 GB Memory, the CPU-then-memory algorithm would pick (2 CPUs, 5 GB Memory), whereas the current code would choose (1 CPU, 10 GB Memory)

The downside of this approach is similar to the current downside -- if you have a provider with a Hardware Profile with a small number of CPUs and a huge amount of Memory, that would be chosen before a potentially cheaper profile with a slightly larger number of CPUs and a smaller amount of memory.
Comment 4 Scott Seago 2012-03-08 20:43:59 EST
Actually I got the numbers wrong in that example. Ignore the second-to-last paragraph and read this one instead:

It could be that, like you say, we could match CPU first and only consider
memory if there were more than one matching profile with an equal number of
Virtual CPUs. So, for example, if we had (5 CPU, 2 GB Memory), (2 CPUs, 5 GB
Memory), (2 CPUs 10 GB Memory), and the user had asked for at least 1 CPU, 2 GB
Memory, the CPU-then-memory algorithm would pick (2 CPUs, 5 GB Memory), whereas
the current code would choose (5 CPU, 2 GB Memory)
Comment 5 wes hayutin 2012-03-09 10:52:30 EST

*** This bug has been marked as a duplicate of bug 790664 ***

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