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