Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): [root@jsefler-r63-server ~]# rpm -q subscription-manager subscription-manager-0.99.12-1.git.5.5f0e228.el6.x86_64 Steps to Reproduce: [root@jsefler-r63-server ~]# subscription-manager register --username testuser1 --password password --org admin --force The system with UUID eb68212f-3283-4c89-99df-3a78bc767362 has been unregistered The system has been registered with id: e1eee1e0-ade3-4802-8538-0757c70fda18 [root@jsefler-r63-server ~]# subscription-manager release Release not set [root@jsefler-r63-server ~]# subscription-manager release --set FOO Release set to: FOO [root@jsefler-r63-server ~]# subscription-manager release --set="" Release: FOO [root@jsefler-r63-server ~]# subscription-manager release --set= Release: FOO [root@jsefler-r63-server ~]# subscription-manager release --set "" Release: FOO ^^^^^^^^^^^^ Expected: "Release not set" Attempts to unset the release are failing. Besides re-registering, is there another way to unset a poorly set release value?
Fixed in master branch: 85b766aa49e9b129126d4b166b3008aedf33bf53 Available in subscription-manager-0.99.13-1+
Verifying Version... [root@jsefler-r63-server ~]# rpm -q subscription-manager subscription-manager-0.99.12-1.git.7.85b766a.el6.x86_64 [root@jsefler-r63-server ~]# subscription-manager release --set FOO Release set to: FOO [root@jsefler-r63-server ~]# subscription-manager release --set "" Release set to: This was not exactly what I asked for, however a release set to "" is effectively treated the same as a release that is not set as demonstrated below.... [root@jsefler-r63-server ~]# subscription-manager register --username testuser1 --password password --org admin --force The system has been registered with id: afa5c86b-b673-489c-a53d-ceac79bf0256 [root@jsefler-r63-server ~]# subscription-manager list --avail | grep awesomeos-virt-unlimited -A1 -B1 Product Name: Awesome OS with unlimited virtual guests Product Id: awesomeos-virt-unlimited Pool Id: 8a90f814365bc7e101365bc8dc240470 -- Product Name: Awesome OS with unlimited virtual guests Product Id: awesomeos-virt-unlimited Pool Id: 8a90f814365bc7e101365bc8dc030468 [root@jsefler-r63-server ~]# subscription-manager subscribe --pool 8a90f814365bc7e101365bc8dc240470 Successfully consumed a subscription from the pool with id 8a90f814365bc7e101365bc8dc240470. [root@jsefler-r63-server ~]# subscription-manager release Release not set [root@jsefler-r63-server ~]# subscription-manager repos --list +----------------------------------------------------------+ Entitled Repositories in /etc/yum.repos.d/redhat.repo +----------------------------------------------------------+ Repo Name: never-enabled-content Repo Id: never-enabled-content Repo Url: https://cdn.redhat.com/foo/path/never Enabled: 0 Repo Name: always-enabled-content Repo Id: always-enabled-content Repo Url: https://cdn.redhat.com/foo/path/always/$releasever Enabled: 1 Repo Name: content Repo Id: content-label Repo Url: https://cdn.redhat.com/foo/path Enabled: 1 [root@jsefler-r63-server ~]# subscription-manager release --set FOO Release set to: FOO [root@jsefler-r63-server ~]# subscription-manager repos --list +----------------------------------------------------------+ Entitled Repositories in /etc/yum.repos.d/redhat.repo +----------------------------------------------------------+ Repo Name: never-enabled-content Repo Id: never-enabled-content Repo Url: https://cdn.redhat.com/foo/path/never Enabled: 0 Repo Name: always-enabled-content Repo Id: always-enabled-content Repo Url: https://cdn.redhat.com/foo/path/always/FOO Enabled: 1 Repo Name: content Repo Id: content-label Repo Url: https://cdn.redhat.com/foo/path Enabled: 1 [root@jsefler-r63-server ~]# subscription-manager release --set "" Release set to: [root@jsefler-r63-server ~]# subscription-manager repos --list +----------------------------------------------------------+ Entitled Repositories in /etc/yum.repos.d/redhat.repo +----------------------------------------------------------+ Repo Name: never-enabled-content Repo Id: never-enabled-content Repo Url: https://cdn.redhat.com/foo/path/never Enabled: 0 Repo Name: always-enabled-content Repo Id: always-enabled-content Repo Url: https://cdn.redhat.com/foo/path/always/$releasever Enabled: 1 Repo Name: content Repo Id: content-label Repo Url: https://cdn.redhat.com/foo/path Enabled: 1 [root@jsefler-r63-server ~]# VERIFIED that $releasever is substituted when release is set to "FOO" and is not substituted when release is set to "" or not set at all.
Is the message, the part that was missed? [root@jsefler-r63-server ~]# subscription-manager release --set "" Release: FOO ^^^^^^^^^^^^ Expected: "Release not set" <<<<< HERE If so, I decided to output "Release set to: " because I found that outputting "Release not set" might be misleading to the user in this case -- Did the operation fail, and nothing changed? Perhaps we could come up with something else for this case? "Release now unset.", "Release unset.", others? Should be a simple change either way. What's your preference?
The original problem was that there was no way to unset the releaseVer on the consumer object. As such I tried to set it to an empty string "" hoping that it would effectively unset releaseVer. Michael's fix in comment 1 now allows me to set the releaseVer to "" which effectively behaves like an unset (null) releaseVer. Since Michael was concerned that "Release not set" might be misleading after calling subscription-manager release --set "", he instead opted to provide feedback stating "Release set to: ". Either solution can be argued as misleading to somebody. Afterall we are using a --set operation to double as an unset operation when the value is "". In my opinion the right solution is to have a --unset option for the CLI tool. And when "" is passed to the --set option, then the value is truely "", and "" does not behave like an unset (null) releaseVer. However, I suspect it is easier to keep the current solution so that in the GUI, when "" is chosen as the system preference drop-down selection for releaseVer, then the value is effectively unset. For now, let's leave the solution in comment #1 as is. Moving to VERIFIED.
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-2012-0804.html