Hide Forgot
Currently the puppet classes for rhevm & vmware create new hardware profiles to ensure that a match can be found on each of the providers. This is misleading, because for instance the vsphere-hwp can also match resources on amazon ec2 and it will appear strange to an end user to see a deployable launching resources in amazon when they thought they specified a vsphere specific hwp. On #aeolus, sseago recommended, "we should probably define two "default" HWPs in the configure script. one 32 bit, one 64 bit, something like 1.5 GB RAM (at least for the 32 bit one so we can match m1.small), and leave storage blank" sseago also noted on channel that the test plan for this needs to include launches on both RHEV and VMWare, as there is some doubt on how RHEV will handle a nil value for storage.
So with RHEV, the issue is that there are RANGE values (instead of fixed ones like ec2 has). A Range HWP property specifies Min, Max, and Default values. What we need to do in condormatic is to make sure that if a match is made where the conductor-specified HWP property is nil, we always use the default value for the HWP range or enum property.
Fixed in aeolus-configure-2.0.1-1.fc14.20110720182607git42b1e20.noarch.rpm
No need to create different realms for providers like RHEV and vmware hwp1 is the generic profile for all providers.
release pending...
perm close