| Summary: | RFE: building for rhevm,vsphere initiates two libvirt installs, should only need one | ||
|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | wes hayutin <whayutin> |
| Component: | imagefactory | Assignee: | Ian McLeod <imcleod> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Martin Kočí <mkoci> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.0.0 | CC: | akarol, brad, dajohnso, deltacloud-maint, dgao, morazi, ssachdev, whayutin |
| Target Milestone: | rc | Keywords: | FutureFeature, Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-03-26 13:45:26 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
This is expected behaviour. Under the default configuration, for each target/template combination we build a JEOS image, customize it, tag it with cloud-info information and then transform it into an on-disk format appropriate for the target (qcow2 or raw for RHEV-M, vmdk streaming format for ESXi) The only optimization currently available to us is to re-use the JEOS image created as the first step in Oz's image building. However, for a couple of reasons we expect to have to disable this for pending releases. (It doesn't always work and a recent fix to allow RHEL5 vsphere to build successfully "pollutes" the JEOS build created during the build step.) Closing as NOTABUG. I'd suggest we open up a general discussion of optimization options we can implement in future releases. adding to ce-sprint removing ce-sprint-next tracker moving version to 1.0.0 . version = found in version We probably need to discuss this. Per previous, "fixing" this would likely mean a pretty major redo of IF guts, if it's possible at all. Ian, let's convene the right stakeholders when you get back. We have actually implemented precisely the optimization discussed here as part of the 2.0 development stream. Specifically, by adding the notion of a BaseImage we allow clients to first create a truly generic build of their TDL, then customize on demand for different targets. The customization always starts with the work that has already been completed during the creation of the BaseImage. Thus the work of doing the anaconda install and JEOS customization is never repeated. I'd suggest we close this as RESOLVED upstream. Closing as this is now addressed in the upstream release of Image Factory |
Description of problem: Using the same system template I kicked off a build via the webui for vsphere,rhevm [whayutin@whayutin Audrey]$ cat audrey-client-RHEL6-rhevm-vsphere.tpl <template> <name>audrey-client-RHEL6-rhevm</name> <os> <name>RHEL-6</name> <version>1</version> <arch>x86_64</arch> <install type="url"> <url>http://download.devel.redhat.com/released/RHEL-6-Server/6.1/x86_64/os/</url> </install> <rootpw>dog8code</rootpw> </os> <repositories> <repository name="aeolus"> <url>http://repos.fedorapeople.org/repos/aeolus/conductor/testing/6Server/x86_64/</url> <signed>False</signed> </repository> <repository name="RHEL"> <url>http://download.devel.redhat.com/released/RHEL-6-Server/6.1/x86_64/os/</url> </repository> <repository name="RHEL-optional"> <url>http://download.devel.redhat.com/released/RHEL-6-Server/6.1/optional/x86_64/os/</url> </repository> <repository name="rhev-agent"> <url>http://download.devel.redhat.com/rel-eng/rhev3-internal-beta-latest/</url> <signed>false</signed> </repository> <repository name='vmwareTools'> <url>http://packages.vmware.com/tools/esx/4.1latest/rhel6/x86_64/</url> <signed>False</signed> </repository> </repositories> <packages> <package name="aeolus-audrey-agent"/> <package name='rhev-agent'/> <package name='vmware-open-vm-tools'/> </packages> <description>RHEL61 x86_64 </description> </template> The imagefactory logs indicate that there were two libvirt installs for the same template??? Shouldnt the template be built via oz once, and xformed to vmdk and qcow2? [root@qeblade32 yum.repos.d]# rpm -qa | grep aeolus aeolus-configure-2.5.0-3.el6.noarch rubygem-aeolus-image-0.3.0-2.el6.noarch aeolus-conductor-0.8.0-5.el6.noarch rubygem-aeolus-cli-0.3.0-3.el6.noarch aeolus-conductor-doc-0.8.0-5.el6.noarch aeolus-conductor-daemons-0.8.0-5.el6.noarch aeolus-all-0.8.0-5.el6.noarch [root@qeblade32 yum.repos.d]# rpm -qa | grep factory imagefactory-jeosconf-ec2-rhel-1.0.0rc2.1-1.el6.noarch imagefactory-1.0.0rc2.1-1.el6.noarch imagefactory-jeosconf-ec2-fedora-1.0.0rc2.1-1.el6.noarch rubygem-imagefactory-console-0.4.0-1.el6.noarch [root@qeblade32 yum.repos.d]# rpm -qa | grep oz oz-0.7.9-7.el6.noarch