Bug 812113
| Summary: | Ensure in --helps that Proxy config only shows when relevant | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Matt Reid <mreid> |
| Component: | subscription-manager | Assignee: | candlepin-bugs |
| Status: | CLOSED NOTABUG | QA Contact: | Entitlement Bugs <entitlement-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | bkearney, jesusr, jsefler |
| Target Milestone: | beta | ||
| Target Release: | 7.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-08-06 15:03: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: | 863175 | ||
|
Description
Matt Reid
2012-04-12 18:55:59 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. 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. (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 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... |