I would vote for this not being a RHEL510 blocker. I think the new behaviour is reasonable given the scenario, though not as optimal as suggested behaviour. Seems like a good 6.5 candidate.



Though, ignoring difficulty, I would think my preferred approach in this scenario would be to try to bind to all the pools with one bind call, and fail
the entire transaction, and provide details on what failed and why. But we
don't actually have candlepin API to do that at the moment.

Current behaviour, or the previous behaviour, don't actually do what the user has asked for ('subscribe me to all of these pools'). The previous behaviour tries to subscribe to all the pulls, but only actually subscribes to some of them, and largely ignores errors. The current behaviour will only try to subscribe to the
pools it processes before hitting the error (which could be none, or all but the last), but does provide an error and exit code.

commit 9ae3ff13d9ac36ef4d97937e197fc119866fe9b7
Author: ckozak <ckozak>
Date:   Mon Aug 26 13:02:07 2013 -0400

    995597: continue attaching if a pool cannot be found

Verifying Version...
[root@jsefler-6 ~]# subscription-manager version
server type: This system is currently not registered.
subscription management server: 0.8.23-1
subscription-manager: 1.9.6-1.el6
python-rhsm: 1.9.6-1.el6


[root@jsefler-6 ~]# subscription-manager orgs --username=testuser1 --password=password
+-------------------------------------------+
          testuser1 Organizations
+-------------------------------------------+

Name: Admin Owner
Key:  admin

Name: Snow White
Key:  snowwhite

[root@jsefler-6 ~]# subscription-manager register --username=testuser1 --password=password --org=admin --force
The system has been registered with ID: 0aa60bc1-754c-4518-a0c3-71606aee2ae4 
[root@jsefler-6 ~]# subscription-manager list --avail | grep "Pool ID" | tail -2
Pool ID:           8a9086d340d0ae7d0140d0afeaeb0705
Pool ID:           8a9086d340d0ae7d0140d0afeb0c0712
[root@jsefler-6 ~]# subscription-manager register --username=testuser1 --password=password --org=snowwhite --force
The system with UUID 0aa60bc1-754c-4518-a0c3-71606aee2ae4 has been unregistered
The system has been registered with ID: 309bad68-d17f-4370-bbf6-2b10304d2fda 
[root@jsefler-6 ~]# subscription-manager list --avail | grep "Pool ID" | tail -2
Pool ID:           8a9086d340d0ae7d0140d0b006330f43
Pool ID:           8a9086d340d0ae7d0140d0b006510f4f
[root@jsefler-6 ~]# subscription-manager attach --pool=8a9086d340d0ae7d0140d0afeaeb0705 --pool=8a9086d340d0ae7d0140d0b006330f43 --pool=bad123 --pool=8a9086d340d0ae7d0140d0afeb0c0712 --pool=8a9086d340d0ae7d0140d0b006510f4f
Insufficient permissions
Successfully attached a subscription for: Awesome OS for x86_64
Pool with id bad123 could not be found.
Insufficient permissions
Successfully attached a subscription for: Awesome OS for x86_64
[root@jsefler-6 ~]# echo $?
0


VERIFIED: When attaching subscriptions from multiple pools (mixture of good, bad, and from other orgs), each pool is once again processed until all the requested pools have been attempted.

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.

http://rhn.redhat.com/errata/RHBA-2013-1659.html