Hide Forgot
Description of problem: I have a series of screenshots to help explain the issue.. I end up w/ an error.. Some component blueprints will not be launched: Component blueprint cloud resource profile architecture (x86_64) doesn't match cloud resource profile architecture (i386). I am unable to get hwp match just using i386.. but vsphere back end realm is reporting a match for x86_64,i386. A user would think you could launch an i386 vsphere image Properties Name Unit Minimum Value memory MB 512 cpu count 1 storage GB n/a architecture label x86_64 Matching Provider Cloud Resource Profiles Cloud Resource Provider Name Cloud Resource Profile Name Architecture Memory Storage Virtual CPU mock m1-large x86_64 7680 - 15360 850, 1024 1 - 6 ec2-us-east-1 c1.xlarge x86_64 7168 1690 20 ec2-us-west-1 c1.xlarge x86_64 7168 1690 20 vsphere-default default x86_64, i386 512 - 2048 1 - 4 rhevm-default SERVER x86_64 512 - 32768 1 - 102400 1 - 16 see screenshots..
Created attachment 564012 [details] ss1 ss1
Created attachment 564013 [details] ss2 ss2
Created attachment 564014 [details] ss3 ss3
Created attachment 564015 [details] ss4 ss4
given... I should be able to create a hwp profile on vsphere that is just i386.. still looking into that. This issue originally reported by Rehana, cc'ing her on bug
opened related bug 795489... which is for inability to create a i386 hardware profile
Assigning to Scott, he's the only one who understands how this matching voodoo works.
From the screenshots, the HWP chosen ("default") is x86_64. The vSphere HWP matches either x86_64 or i386, but the user-specified "default" is x86_64, so when it matches vSphere, it chooses x86_64 on the back end. In fact, looking at the error message: Component blueprint cloud resource profile architecture (x86_64) doesn't match cloud resource profile architecture (i386). it appears to be saying the same thing -- the "Component blueprint cloud resource profile architecture" seems to refer to the HWP associated with the assembly (component blueprint). Try this again with an i386 front-end HWP.
(In reply to comment #8) > Try this again with an i386 front-end HWP. My understanding is that part of the problem is that none are created after running aeolus-configure. Is it an expected that the customer would manually setup i386 Hardware profiles for i386 deployments?
I would expect that the admin would configure HWPs to meet their local needs. That said, it would make sense to me to make creation of an i386 HWP as an option for aeolus-configure if we expect a majority of customers to actually want to launch 32 bit instances. Do we have any idea how important 32 bit instances are to customers?
*** Bug 795489 has been marked as a duplicate of this bug. ***
This issue should not block beta 2 -- we are in the midst of a PM discussion about whether it should even be dealt with for the product. Removing the blocker request.
My understanding is that if an Admin properly configures their HWPs, the system functionality will be as expected. This can be addressed in release notes/users docs. So, if that is a correct assumption, then I agree this should not be a blocker.
So .. this is moving to docs.. the nut and bolts are this.. We are going to document the procedure for building/pushing/launching i386 as a x386_64 instance using an x86-64 hwp
I have documented the workaround for this issue and am moving it to 1.1.0. The correct fix, to modify hardware profile matching so that 32-bit images will match 64-bit hardware profiles on clouds which support that, is too invasive for this release.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cloud Engine hardware profile matching does not support 32-bit instances for this release. The workaround for running 32-bit OSes is for the user to create a Component Outline for a 64-bit instance that installs a 32-bit OS. In fact, this is precisely what will happen on clouds powered by RHEV-M and vSphere regardless of hardware profile. In a future release, we will allow users to create 32-bit Component Outlines and match them to 64-bit hardware profiles if there are no 32-bit profiles available.
Angus -- are we really saying that modifying matching rules here is in scope for 1.1? If so, this is probably best assigned to someone that's worked on the matching code lately, since that's changed so much.
Given the short remaining time for new feature development in 1.1, modifying matching rules is not in scope for 1.1.
Closing as Cloud Engine is no longer maintained, and there is no 2.0 release planned.