In conductor, four properties are considered during hardware profile matching, in this order: memory, cpu, storage, and architecture. A front end hardware profile and a back end hardware profile are deemed a match if all four properties are in agreement. If a property is numeric, then match is found if the front end value is less than or equal to the back-end value or the maximum back-end value if it is specified as a range. If nil is specified as a property for a front-end hardware profile, then it matches with everything. If nil is specified as a property for a back-end hardware profile, then it matches only if the front-end property was also nil. When there are multiple matches, the backend hardware profile with the least amount of memory is chosen.
Previously a single architecture was listed for each EC2 provider hardware profile. In a few cases, m1.small and c1.medium, only i386 was listed and x86_64 was omitted. Conductor also assumed a single architecture for each hardware profile.
To allow us to start using smaller sized instances for EC2 for the x86_64 architecture, Deltacloud was changed so that it listed both i386 and x86_64 as architectures for m1.small and c1.medium.
And Conductor was changed so that it considered all architectures that are listed in a provider hardware profile.
Unchanged, Conductor would only see the first architecture that is listed by Deltacloud. Now Conductor will see x64_64 as an architecture for m1.small during matching. And will pick m1.small (1.7GB memory) over c1.xlarge (7GB memory) and m1.large (7.5GB memory).