Bug 747399 - if consumer does not have architecture then we should not check for it
if consumer does not have architecture then we should not check for it
Product: Candlepin
Classification: Community
Component: candlepin (Show other bugs)
Unspecified Solaris
unspecified Severity high
: ---
: ---
Assigned To: Devan Goodwin
John Sefler
Depends On:
Blocks: rhsm-rhel62
  Show dependency treegraph
Reported: 2011-10-19 13:33 EDT by blittle
Modified: 2015-05-14 11:22 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-04-20 11:16:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description blittle 2011-10-19 13:33:43 EDT
Description of problem:
Unable to bind cloud subscriptions to rhui consumers

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

How reproducible:

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 10:12:06 EDT
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 10:45:13 EDT
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 15:18:44 EDT
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 17:09:59 EDT
Verified that this is fixed from our side in Dev2 with the new build.

Note You need to log in before you can comment on or make changes to this bug.