Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 747399

Summary:	if consumer does not have architecture then we should not check for it
Product:	[Community] Candlepin (Migrated to Jira)	Reporter:	blittle
Component:	candlepin	Assignee:	Devan Goodwin <dgoodwin>
Status:	CLOSED CURRENTRELEASE	QA Contact:	John Sefler <jsefler>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	0.5	CC:	acarter, dgoodwin, sshevach
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Solaris
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-04-20 15:16:09 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	682238

Description blittle 2011-10-19 17:33:43 UTC

Description of problem:
Unable to bind cloud subscriptions to rhui consumers

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. Login to the https://rails-fte.gss.devlab.phx1.redhat.com/management/
2. User--rhn-cservice-acarter pw-redhat
3. Create a rhui consumer and try to bind a subscription to a consumer.
  
Actual results:
The cloud provider subscriptions do not bind to the consumer

Expected results:
The cloud provider subscription should bind to a consumer.

Additional info:

Comment 1 Devan Goodwin 2011-10-21 14:12:06 UTC

Some questions:

(1) Do you want all consumers with no architecture to be able to bypass this check? Or should this be a specific exception for consumer type "rhui". (is that the exact consumer type label?)

(2) Is this just specific to architecture, or do we have other rules to worry about? (virt_only, sockets, etc)

Comment 2 Amanda Carter 2011-10-21 14:45:13 UTC

This should apply to any consumer with no arch set -- today this would include RHUI, Domain and SAM -- CloudForms later. 

We've already updated the JS rules to not check for socket limit if it is not present. An email was just sent about not checking on required consumer type for 'export enabled = true' consumer types also. Essentially, 'export enabled = true' consumers should not check on anything, other than limiting virt pool display, at this time (ie we want you to be able to put all subscriptions on them).

I don't think there are any other filtering checks from the web perspective since we're not using 'installed product'. When that rolls out, we may need to revisit rules?

Comment 3 Devan Goodwin 2011-10-24 19:18:44 UTC

Fixed in master: 0d0094e620efc179afdf84fae8b4ff07b9fe1282

Any consumer without an arch fact and whose type is not system will be allowed to pass the rule.

Comment 4 Amanda Carter 2011-10-27 21:09:59 UTC

Verified that this is fixed from our side in Dev2 with the new build.