Hide Forgot
Description of problem: It is currently necessary for all custom rpm content to be hosted in public repositories so that remote provisioning via ec2 can locate the bits. During testing/development I assumed it would be possible to host content in a repo local to the aeolus conductor box. Imagefactory should be enhanced to allow users to specify builds that can reference iso content and add additional custom rpm content for private cloud content provisioning. Supporting the addition of repositories local to the conductor box would be very useful for private cloud vendors. Requiring the user to alternatively build out Virtual Private Cloud instance just to host custom rpm content seems unnecessary when Conductor is already orchestrating the OS image definition. Version-Release number of selected component (if applicable): imagefactory-0.2.0_15_g14c6294-1.fc14.noarch How reproducible: N/A Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Support for .tld repository content, like the following, would provide cloud builders with the ability to build/test images customized with proprietary rpms without added complications of secure hosting of the same. <repositories> <repository name='local-jon-rpms'> <url>http://localhost/rpms</url> </repository> </repositories>
making sure all the bugs are at the right version for future queries
This one appears to be covered by https://www.aeolusproject.org/redmine/issues/2117 Ian, concur?
This has been addressed, in a fairly simple way, inside of Oz using SSH tunnels. The package is available here: http://repos.fedorapeople.org/repos/aeolus/conductor/testing/fedora-15/x86_64/oz-0.7.0-3.fc15.noarch.rpm
It doesn't work for me with oz-0.{8,9} ? I'm getting an exception File "/usr/lib/python2.7/site-packages/oz/TDL.py", line 331, in _add_repositories raise oz.OzException.OzException("Repositories cannot be localhost, since they must be reachable from the guest operating system") oz.OzException.OzException: Repositories cannot be localhost, since they must be reachable from the guest operating system Or does this message mean how it should work ? If so I would move bug to VERIFIED. Thanks
The message looks OK to me as it does better messaging about why this is not supported and fails on build. Moving bug to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-0588.html