Description of problem: The Conductor UI explicitly shows images as scoped to a Pool Family, but the image creation code does not set this in the iwhd metadata, nor does the image retrieval code filter on the pool family. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Go to the details page for a Pool Family 2.Go to the images tab 3. Actual results: You see all images, even those created under different pool families. Expected results: Only images created under this pool family should show up. Additional info: If we fix the scoping problem after 1.0, there is potentially a big upgradability problem. Once we have conductor with real data, real images, etc. if images are not yet scoped, you may have one (unscoped) image list with multiple pool families in use, deployables referencing various combinations of iamges, etc. In this situation going back and attempting to scope each image to a single Pool Family may be impossible. It will be much easier to do this now.
Steps needed: 1) add ability in aeolus-image-rubygem to add pool family metadata key, filter on it, etc. 2) in UI where we create images, set pool family metadata key. 3) in CLI where we create images, set pool family metadata key. 4) in Images UI for pool family, filter on pool family 5) set per-pool family permissions for images 6) in deployable validation, make sure that all referenced images belong to the same pool family in which resides the pool connected to the deployable's catalog 7) don't allow a deployable to be shared across catalogs spanning more than one pool family.
I agree w/ Scott, I'm noticing the scope of images introducing problems through out the UI.
Patches posted: https://fedorahosted.org/pipermail/aeolus-devel/2012-February/008879.html https://fedorahosted.org/pipermail/aeolus-devel/2012-February/008880.html https://fedorahosted.org/pipermail/aeolus-devel/2012-February/008881.html
github/master for aeolus-cli: 70a7bd40773810b98a20571b4a8437b354169c3c github/master for aeolus-image-rubygem: 1622d30f4d4b9ae701b1ad255d583feade1b8f4d github/master for conductor: 45f261622a63e9136b0ea21ae7b1de9be2b4b4ea
commits in sseago's most recent comment are in latest aeolus-conductor-0.8.0-30 and rubygem-aeolus-cli-0.3.0-9 and rubygem-aeolus-image-0.3.0-8
pool set where images are built via webui pool set via cli pool set via webui import pool set via cli import verified [root@qeblade30 yum.repos.d]# rpm -qa | grep aeolus rubygem-aeolus-image-0.3.0-10.el6.noarch aeolus-conductor-0.8.0-37.el6.noarch rubygem-aeolus-cli-0.3.0-11.el6.noarch aeolus-conductor-daemons-0.8.0-37.el6.noarch aeolus-all-0.8.0-37.el6.noarch aeolus-conductor-doc-0.8.0-37.el6.noarch aeolus-configure-2.5.0-15.el6.noarch [root@qeblade30 yum.repos.d]#
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-0583.html