The "No Products Installed" behavior looks like a consequence of bug 1123014

Sorry, should be:


Expected results:
Exit code of 0

Same problem exists when you try to register system by consumerid

subscription-manager register --org="Default_Organization" --consumerid="34f08233-e625-4f8b-abd5-792651ffc9e7"  --username=<USER> --password=<PASS>

echo $?
>> 1

*** Bug 1138675 has been marked as a duplicate of this bug. ***

Moving bugs to 6.7

Moving bugs to 6.7

Moving bugs to 6.7

(In reply to Pavel Studeník from comment #3)
> Same problem exists when you try to register system by consumerid
> 
> subscription-manager register --org="Default_Organization"
> --consumerid="34f08233-e625-4f8b-abd5-792651ffc9e7"  --username=<USER>
> --password=<PASS>
> 
> echo $?
> >> 1

The erroneous exitCode from registering with a consumerid is not the same problem as comment 0; no activation key is involved.   This issue has been fixed by bug 1145835.

commit afd16e96d89ff38f74c60fd23613b67e27da17c5
Author: Chris Rog <crog>
Date:   Mon Dec 8 11:17:15 2014 -0500

    1132981: Fixed exit code when registering system with no products installed
    
    - When registering a system that does not have any products installed via
      consumerid or activation key, the system will no longer return an exit
      code of 1.

(In reply to Chris Rog from comment #9)
> commit afd16e96d89ff38f74c60fd23613b67e27da17c5

shows the following code change...

 def show_autosubscribe_output(uep):
     installed_status = get_installed_product_status(inj.require(inj.PROD_DIR),
             inj.require(inj.ENT_DIR), uep)
+
     if not installed_status:
-        print _("No products installed.")
-        return 1
+        # Returning an error code here breaks registering when no products are installed, and the
+        # AttachCommand already performs this check before calling.
+        return 0


I disagree with this change for two reasons:

1. It is a regression of long-time behavior bug 689608 which explicitly asks for a non-zero exit code when no entitlements are granted during an auto subscribe.  I suspect that Justin's activation key contained an "auto-attach" field which is why his activation key was trying to auto subscribe.  If yes, then the exit code of 1 is working as designed and the feedback of "No products installed." is a clue to tell him why.

2. It is a regression of usability bug 962545 which explicitly added "No products installed." as feedback during a call to subscription-manager register --autosubscribe

In my opinion, commit afd16e96d89ff38f74c60fd23613b67e27da17c5 should be reverted and the response to this bug is close it, working as designed, because the next guy who tries to register with an activation key that contains an auto-attach=true attribute and gets no entitlements with no feedback and an exit code of zero is going to question...  "Why didn't my activation key give me a subscription?".

John,

I do not believe that the activation key had auto-attach set to true.  I will do testing though to verify.  Regardless, I'm not sure that auto-attach should be considered 'failure' if there are no installed products.  In that situation auto-attach is a no-op and should not fail.  the way I see all installed products (none) properly had a subscription attached so the system is 'green'.  If it had a single installed product for which a subscription could not be found then it should fail.  But i could see where that is up for debate.

I think that https://bugzilla.redhat.com/show_bug.cgi?id=689608 was making an assumption that all systems would have installed products, which is not the case for cent os and rhel derivatives that katello supports. 

-Justin

I would say that it should still print a warning if no products are installed.

(In reply to Justin Sherrill from comment #12)
> I would say that it should still print a warning if no products are

QE agreed

I would also say that we are overloading the meaning of the exit code value which is very difficult to understand since a non-zero does not necessarily imply a failure as Justin interpreted it in comment 0.  The exit code of 1 in comment 0 was supposed to be interpreted to mean that no entitlements were granted as a result of the transaction (as designed in bug 689608).  Moreover, we also are combining two operations (register and subscribe) into one call that returns one exit code.  I don't think there is any correct answer here other than to stop making decisions on the exit code from registering with activationkey/autosubscribe options.

commit b9e42b05ebd3529c25dc18a520e3f7a85db1b939
Author: Chris Rog <crog>
Date:   Fri Dec 12 12:30:37 2014 -0500

    1132981: Reverted removal of warning message

exit code is now 0,hence marking verified!!

[root@dhcp35-236 ~]# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.9.49-1
subscription management rules: 5.15
subscription-manager: 1.14.5-1.el6
python-rhsm: 1.14.2-1.el6


[root@dhcp35-236 ~]# subscription-manager register --force --activationkey Test_key2 --org donaldduck
The system has been registered with ID: 1fc6846b-4f30-432f-aecb-ca13bce56609 
2 local certificates have been deleted.

No products installed.
[root@dhcp35-236 ~]# echo $?
0

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.

https://rhn.redhat.com/errata/RHBA-2015-1345.html