[RFE] Build image preview information

Andy Goldstein andy.goldstein at redhat.com
Thu Aug 2 15:59:21 UTC 2012


On Aug 2, 2012, at 11:51 AM, Ian McLeod wrote:

> On Thu, 2012-08-02 at 07:56 -0400, Andy Goldstein wrote:
>> Hi all,
>> 
>> I was working with CloudForms 1.0/Conductor yesterday and ran into an issue that had me banging my head against the desk for a while.  I had an ImageFactory /etc/imagefactory/target_content.xml file configured to point to several repos in Katello.  In Conductor, I provided an image XML file that pointed to some other (different) repos.  When I went to build my image, I kept getting an older version of an RPM installed, and I was *certain* that I had a newer version available.  It turns out that the RPM was available in both a repo from target_content.xml and from a repo in my image XML.  I'm guessing the repos didn't have any priorities set, and yum just picked the first repo in the list that contained my RPM.  Unfortunately for me, it was the older version.  Once I promoted the newer version to the repo specified by target_content.xml, all was good.
> 
> That still doesn't really explain the behavior you are seeing.  If a
> package is present in multiple repos, yum should select the newest
> version available during install, yeah?
> 
> That's certainly what happens for me all the time in Fedora.  If I
> install a package that happens to be present in both the core and
> updates repos, I get the update version because it is newer.

Does yum go off or repo priority, or, if no priorities are given, whichever repo is first?  Or is it supposed to select the newest package from across all repos?

> 
>> So here's my RFE: I think it would be great if there was some way to preview what will happen when you click "build image."  At a minimum, I would like to see a list of all the repos (in order) and a list of all packages (and if possible, their versions) that will be installed.
> 
> We could, in theory, do the following:
> 
> 1) Provide an API expansion to allow a client to request this preview in
> the first place.

+1

> 
> 2) Provide, through this API, a human readable version of what it is,
> exactly, that we are going to attempt during customization.  (Which
> would be more or less what you requested.)

+1

> 
> 3) Provide a better log of what actually happened during customization
> (though this will end up being quite lengthy in certain situations).

+1

> 
> What we cannot easily do is report what yum is going to attempt without
> actually running yum on a real guest pointing at the actual repos.

In theory, couldn't you set up an --installroot that only contained repo information for what the guest would be using, and then do a dry run using that?

> 
> I suppose we could do exactly that as part of producing the output for
> 2.  Do our normal customization routine only "dry run" yum instead of
> really running it.  Still, you'd probably rather just try to do the
> customization and then read the detailed log if the outcome is not what
> you expected, yes?
> 
> -Ian

All I can say is I was getting increasingly frustrated as I continued to try to tweak things and then rebuild the image over an over again.  Each build easily took 10 to 15 minutes (granted, the hardware we were using was in a training lab and not server-grade), so productivity was certainly an issue.  At the very least, being able to see what was actually done (#3 from above) would be preferable to what I was doing initially, which was building the image, pushing to RHEVM, launching the image via Conductor, and then SSH'ing in to the instance to see what was installed.  I later realized I could use guestfish on the image to see what was installed prior to any push/launch, which was much better.

Andy


More information about the aeolus-devel mailing list