Bug 812113 - Ensure in --helps that Proxy config only shows when relevant
Ensure in --helps that Proxy config only shows when relevant
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: subscription-manager (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: beta
: 7.0
Assigned To: candlepin-bugs
Entitlement Bugs
:
Depends On:
Blocks: rhsm-rhel70
  Show dependency treegraph
 
Reported: 2012-04-12 14:55 EDT by Matt Reid
Modified: 2013-08-07 16:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-06 11:03:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Reid 2012-04-12 14:55:59 EDT
Description of problem:
Currently we show proxy configuration info in most subscription-manager modules, but not all. I'd like to double-check that we're showing it only when useful to the user (ie relies on internet connectivity), and not cluttering up --help with unimportant commands that they don't need to see at that point in time.

Primary Modules:
List (proxy)
Refresh (proxy)
Register (proxy)
Release (proxy)
Subscribe (proxy)
Unregister (proxy)
Unsubscribe (proxy)

Secondary Modules:
Clean
Config (different proxy config)
Environments (proxy)
Facts (proxy)
Identity (proxy)
Import
Orgs (proxy)
Redeem (proxy)
Repos
Service-Level (proxy)

I feel like we don't need to include it in Unregister, Unsubscribe, Facts, Identity, and Service-Level, but maybe there's merit to keeping it there. Seems like it might be nice to have a dedicated Proxy module, but sounds like there could difficulties implementing that and could potentially break existing automation scripts.

Should proxy info be everywhere it currently is?


Version-Release number of selected component (if applicable):
subscription-manager-1.0.0-1.git.19.46c8d80.fc16

Additional Information:
(proxy) indicates that we list proxy configuration information in that module's --help
When present, it looks the same in all modules, aside from Config, which is handled a bit differently, and is also the only place they can view what their proxy settings are
Comment 1 RHEL Product and Program Management 2012-04-16 22:08:55 EDT
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 3 RHEL Product and Program Management 2012-12-14 03:47:51 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 4 Jesus M. Rodriguez 2013-08-06 11:02:12 EDT
(In reply to Matt Reid from comment #0)
> 
> I feel like we don't need to include it in Unregister, Unsubscribe, Facts,
> Identity, and Service-Level, but maybe there's merit to keeping it there.
> Seems like it might be nice to have a dedicated Proxy module, but sounds
> like there could difficulties implementing that and could potentially break
> existing automation scripts.

The above listed modules DO require internet connectivity. Therefore they require the proxy information.

> Should proxy info be everywhere it currently is?

to the best of my knowledge, yes
Comment 5 Matt Reid 2013-08-07 16:09:22 EDT
It still seems a little silly to me that we have --proxy=PROXY_URL, --proxyuser=PROXY_USER, and --proxypassword=PROXY_PASSWORD littered everywhere. Once they set it once, and register, aren't they never going to touch the proxy stuff again? If the proxy info actually changed, could they update what it points to by doing identity or some nondestructive command and repointing it to some new url/user/password? or would they have to unregister and re-register using the new proxy credentials? (or run clean cause they can't talk to the server anymore)

I feel like this would be better off in its own module, then we could add stuff to let it output what the current proxy settings are, and it wouldn't be in almost all of our current modules, when it will most likely only get used once, maybe, and that's probably at registration time. If there was a network issue or something, we could tell them to run subscription-manager proxy --help, and they'd be able to check/set to their heart's content from there... Or am I not thinking about proxy usage properly and it's common to have to update it (and what we have is able to update cleanly in a round-about fashion)?

If this is the way it has to be, then ok, but I'm not a fan, seems like while we have the basics covered, overall our proxy configuration feels weak to me how it currently is...

Note You need to log in before you can comment on or make changes to this bug.