Bug 786220

Summary:	Scope images to Pool Family
Product:	[Retired] CloudForms Cloud Engine	Reporter:	Scott Seago <sseago>
Component:	aeolus-conductor	Assignee:	Scott Seago <sseago>
Status:	CLOSED ERRATA	QA Contact:	wes hayutin <whayutin>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	1.0.0	CC:	akarol, deltacloud-maint, hbrock, slinaber, ssachdev
Target Milestone:	beta
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-05-15 22:25:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Scott Seago 2012-01-31 18:33:06 UTC

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.

Comment 1 Scott Seago 2012-01-31 18:35:26 UTC

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.

Comment 2 wes hayutin 2012-01-31 21:11:02 UTC

I agree w/ Scott, I'm noticing the scope of images introducing problems through out the UI.

Comment 3 Scott Seago 2012-02-15 19:06:24 UTC

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

Comment 4 Scott Seago 2012-02-19 20:30:49 UTC

github/master for aeolus-cli: 70a7bd40773810b98a20571b4a8437b354169c3c
github/master for aeolus-image-rubygem: 1622d30f4d4b9ae701b1ad255d583feade1b8f4d
github/master for conductor: 45f261622a63e9136b0ea21ae7b1de9be2b4b4ea

Comment 5 Steve Linabery 2012-02-20 21:01:38 UTC

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

Comment 6 wes hayutin 2012-02-27 22:56:55 UTC

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]#

Comment 7 errata-xmlrpc 2012-05-15 22:25:49 UTC

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