Hide Forgot
Description of problem: When I try to register to stage server,failed both in CLI and GUI Version-Release number of selected component (if applicable): python-rhsm-1.17.9-1.el7.x86_64 python-rhsm-certificates-1.17.9-1.el7.x86_64 subscription-manager-1.17.15-1.el7.x86_64 subscription-manager-gui-1.17.15-1.el7.x86_64 subscription-manager-initial-setup-addon-1.17.15-1.el7.x86_64 How reproducible: always Steps to Reproduce: 1.Install build RHEL-7.3-20161019.0 2.Try to register in CLI with valid account information : (new_test/redhat/7967630) [root@dhcp-128-214 ~]# subscription-manager register Registering to: subscription.rhsm.stage.redhat.com:443/subscription Username: new_test Password: Organization: 7967630 'idCert' 3.Try to register in GUI #subscription-manager-gui 4.Input valid account and password,then click 'Register' button Actual results: CLI: return 'idCert'.Then manually check the system has not been registered GUI: after click 'Register' button,stay in the window "Registering" for a long time Expected results: Register successfully both in CLI and GUI Additional info:
Created attachment 1215972 [details] The rhsm.log
Created attachment 1215973 [details] The screenshot after click Register button
Wei, Can we please see more of the rhsm log showing the entire registration process. You may need to edit your rhsm.conf default_log_level to 'DEBUG'. Candlepin devs, We suspect this was the result of maintenance done on stage. If so this is a temporary failure. We need to investigate if there is any case in CP that could cause a successful http return code but not include the 'idCert' property.
I tried again on build RHEL-7.3-20161019.0 but can not reproduce this problem. And the system register successfully: [root@dhcp-129-109 ~]# subscription-manager register Registering to: subscription.rhsm.stage.redhat.com:443/subscription Username: new_test Password: The system has been registered with ID: 5d6f97f7-ce60-4e87-947a-065efa810a2b So I cloud not offer the rhsm.log with the log level=DEBUG .
I've happened upon a reproducer for this issue. In looking through the logs it became evident that the issue was with a 202 response sent from candlepin to subscription-manager as a result of an attempt to create a new consumer. I went splunking in the stage candlepin logs to find that the reason for this was a failure in another service that the ITUserServiceAdapter was using to verify user credentials. The exception raised there was wrapped and thrown as a AcceptedRequestException. This exception (defined by us in candlepin) causes candlepin to create a valid json response with our usual error values (displayMessage etc). In addition it sets the http status code to 202. As a 202 is normally an indication of success python-rhsm treats it as such. This causes subman to attempt to access a key it is expecting in a successful response 'idCert' that is not there in the error response. An example of one of the tracebacks seen in the candlepin logs that indicates the above can be seen at the link below: https://splunk.corp.redhat.com/en-US/app/search/show_source?sid=1478794294.40022_B24C190D-C760-4B5E-B58E-77690A8A7F2C&offset=0&latest_time= I'm going to clone this bug to IT candlepin to request that all use of AcceptedRequestException be stopped and switched to another exception that will return an error code and cause subman to expect error json.
To the candlepin devs, After the work on the service adapters is complete (in bz 1393965) all that should be required of us is to remove AcceptedRequestException from the codebase as it is not necessary.