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.
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.
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.
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.
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)
*** This bug has been marked as a duplicate of bug 790664 ***