Description of problem: Virt only pools in IT's prod candlepin are not available for export in a manifest. The subscriptions do not create a physical pool and are available as expected on virt instances. I expect that we're just not handling these pools like we thought we did but don't know if this is an IT bug or Eng -- starting with Eng. How reproducible: You can see this by logging into the stage_test_58 / redhat account or the stage_test_whitelist3 account in stage. Steps to Reproduce: 1. Create a SAM or CF instance 2. Look for subscription with name 'Red Hat Enterprise Linux for VMware, Premium (up to 2 sockets)' on account stage_test_58 3. It does not appear 4. Create a virt system 5. Look for the same subscription 6. It does appear * The subscription on the stage_test_whitelist3 account is RHEL as a Virtual Guest, Disaster Recovery
Plain virt_only subscriptions do not appear to be blocked for manifest consumer types like sam. Testing locally but it seems ok. I do notice the pool has "enabled_consumer_types" set to "SAM", the consumer's type is "sam", we do not enforce this attribute but does the portal do anything possibly missing case insensitive comparison?
commit ed09185d82eafe2629f0737480040a603d737369 Refs: master, <origin/HEAD>, <origin/master>, candlepin-0.7.25-1-10-ged09185 Merge: b10000d d9391d7 Author: Devan Goodwin <dgoodwin> AuthorDate: Wed Feb 27 09:04:36 2013 -0800 Commit: Devan Goodwin <dgoodwin> CommitDate: Wed Feb 27 09:04:36 2013 -0800 Merge pull request #180 from candlepin/virtonlymaster 909495: Virt-only subscriptions are not exportable This will be available from master in candlepin version 0.7.26 or greater.
Verify... 1. Register account stage_test_58 on host system 2. Look for subscription with name 'Red Hat Enterprise Linux for VMware, Premium (up to 2 sockets)' - MCT0994 # subscription-manager list --avail | grep MCT0994 3. cannot find MCT0994 4. Register account stage_test_58 on virt system 5. Look for the same subscription # subscription-manager list --avail | grep MCT0994 SKU: MCT0994 6. It's successful to find MCT0994 on virt system After the above verification, the virt-only sku MCT0994 still cannot be listed on host system, so moved to ASSIGNED.
This subscription *should not* be available oh a host/physical system. It should only be available on a virt system and on a Distributor. I have just spot checked that this has been resolved. Please just be sure that your test criteria is correct to only expect these subscriptions on virt systems and not on physical systems. This should be true for any subscription that is 'virt-only' identified by having a value of Virtual Guest in the attributes table.
(In reply to comment #9) > This subscription *should not* be available oh a host/physical system. It > should only be available on a virt system and on a Distributor. I have just > spot checked that this has been resolved. > > Please just be sure that your test criteria is correct to only expect these > subscriptions on virt systems and not on physical systems. This should be > true for any subscription that is 'virt-only' identified by having a value > of Virtual Guest in the attributes table. Hi Amanda, Thanks for your clarification, and, I re-test it against stage candlepin, and the following are my test steps: 1. Log into access.stage.redhat.com with account stage_test_58 2. Click 'Subscription Management Applications' -> Create one organization MCT0994 -> Attach a subscription of MCT0994 - Red Hat Enterprise Linux for VMware, Premium (up to 2 sockets) 3. Export this manifest with 'download manifest' button - manifest.zip 4. Prepare one SAM server, and import 'manifest.zip' to SAM server 5. register to the SAM server and check on one virt machine MCT0994 does appear Please help me confirm if my verification process is correct, if yes, please move this bug to VERIFIED, if not, please give me some deeper guide, thanks~ Thanks~ Fengshuang
Looks good to me Fengshuang. In fact this bug previously occurred when just attaching a subscription to a SAM instance so did not require importing the manifest to a SAM, but the scenario you've noted is a full end to end verification of that fix. Thanks!
Thanks for Amanda's patient explanation. And, according to Comment 10 and Comment 11, this bug has been fixed, so move it to VERIFIED.
Closing as no further issues have been reported. Thanks!