Bug 829803

Summary:	[RFE] Add Explicit Unset Command & Unique String to service-level Module
Product:	Red Hat Enterprise Linux 5	Reporter:	Matt Reid <mreid>
Component:	subscription-manager	Assignee:	William Poteat <wpoteat>
Status:	CLOSED ERRATA	QA Contact:	Entitlement Bugs <entitlement-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	5.9	CC:	awood, bkearney, jmolet, skallesh
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-08 03:54:37 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	827225

Description Matt Reid 2012-06-07 15:16:40 UTC

Description of problem:
Currently to remove a preference for service level or release, a user must type in --set "" or --set=, which returns a message of "Release set to:" and "Service level preference not set". I think we should have a unique string for unsetting the preference, something like "Service level preference unset", and then if they do --show on an unset preference, it displays "Service level preference not set". Saying it wasn't set makes it sound like the command was ignored because something went wrong, so while that works fine for --show, I don't think it fits for --set.

We should implement "service-level --unset" to remove their preference without having to know they should set it to be blank.

Adding in an explicit command also lets us expose it in --help, so that it is discoverable. As is, they would need to read documentation (assuming we explained it somewhere) to figure out they unset it by setting it.

Version-Release number of selected component (if applicable):
sub-man 1.0.2-1.git.82.94602c6

Additional info:
We should also do this for the release module, I'll add a BZ for it.

Comment 1 William Poteat 2012-06-07 15:58:01 UTC

The --unset for service level should result in an empty string sent to the backend server for service level. The server should then interpret that value to null for persistence.

Comment 2 Bryan Kearney 2012-06-07 21:05:59 UTC

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

Comment 3 Bryan Kearney 2012-06-14 13:15:55 UTC

fixed in master in bacae2619cdfaf555d2adbe6263fd1b33adca4dc

Comment 4 RHEL Program Management 2012-06-18 17:07:54 UTC

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

Comment 5 Shwetha Kallesh 2012-06-25 10:57:36 UTC

verified!!


RPM verison:
[root@dhcp201-196 ~]# rpm -qa | grep subscription-manager
subscription-manager-gui-1.0.4-1.git.20.0466bff.el5
subscription-manager-migration-data-1.11.1.1-1.git.2.c7fbafe.el5
subscription-manager-firstboot-1.0.4-1.git.20.0466bff.el5
subscription-manager-migration-1.0.4-1.git.20.0466bff.el5
subscription-manager-1.0.4-1.git.20.0466bff.el5


[root@dhcp201-196 ~]# subscription-manager service-level --help | grep unset
  --unset               unset the service level for this system

Comment 7 errata-xmlrpc 2013-01-08 03:54:37 UTC

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-0033.html