Bug 773388 - RFE: building for rhevm,vsphere initiates two libvirt installs, should only need one
Summary: RFE: building for rhevm,vsphere initiates two libvirt installs, should only n...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: imagefactory
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
Assignee: Ian McLeod
QA Contact: Martin Kočí
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-11 17:58 UTC by wes hayutin
Modified: 2014-03-26 13:45 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-26 13:45:26 UTC


Attachments (Terms of Use)

Description wes hayutin 2012-01-11 17:58:02 UTC
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

Comment 1 Ian McLeod 2012-01-11 20:58:23 UTC
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.

Comment 2 wes hayutin 2012-01-12 16:33:45 UTC
adding to ce-sprint

Comment 3 wes hayutin 2012-01-12 16:40:08 UTC
removing ce-sprint-next tracker

Comment 4 wes hayutin 2012-02-22 23:45:38 UTC
moving version to 1.0.0 .  version = found in version

Comment 5 jrd 2012-06-11 19:53:52 UTC
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.

Comment 6 Ian McLeod 2012-08-02 15:34:49 UTC
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.

Comment 7 Ian McLeod 2014-03-26 13:45:26 UTC
Closing as this is now addressed in the upstream release of Image Factory


Note You need to log in before you can comment on or make changes to this bug.