[RFE] Build image preview information

Ian McLeod imcleod at redhat.com
Thu Aug 2 15:51:46 UTC 2012


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.

> 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.

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.)

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

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.

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

> 
> Thanks for listening :-)
> Andy



-- 
Ian McLeod - Red Hat
office: 312.660.3539
mobile: 312.899.6736
rh internal: (81) 33539




More information about the aeolus-devel mailing list