copied from 893090:
  Allan Voss 2013-01-08 09:47:22 EST

1. Proposed title of this feature request
  
   HTTP proxy support for Spice Clients with RHEV

2. Who is the customer behind the request?
   Account name:        State Street
   Customer segment:    3
   TAM/SRM customer:    yes
   Strategic Customer:  yes

3. What is the nature and description of the request?

Customer needs to be able to use an HTTP proxy with RHEV for connecting to spice clients


4. Why does the customer need this? (List the business requirements here)
Customer is currently required to configure host/port for each VM in their environment in order to allow access to VMs over VPN. This is labor-intensive and pushes the VPN server unnecessarily. Allowing for the use of a proxy would remedy this


5. How would the customer like to achieve this? (List the functional
requirements here)

For the implementation, there are two issues: -
1) How the proxy(s) are defined, and
2) Communicating that information to the spice client.

The proof of concept allowed for just a single proxy to be defined in a host:port convention. I recommend extending this to allow multiple proxies to be defined, separated by (say) a semi-colon, with a special case of DIRECT, that indicates to attempt to connect directly. Example: -

proxy1.example.com:3128;DIRECT;proxy2.example.com:3128

The spice client would try each of the proxies until it got a successful connection to a hypervisor. Note that the spice client should be smart enough to manage the case where a proxy accepts the initial connection, but then rejects the subsequent "connect" command. Clearly the default value for the proxy string is "DIRECT".

The second part is how the proxy string is communicated to the spice client. So RHEV-M needs to be able to communicate proxy information to the spice client when starting a spice session. I would suggest that proxy information is naturally an attribute of a RHEV-M Data Center. But an alternate, and simpler approach, might be to just set it as a rhevm-config value so no changes to a user interface are required. I would also recommend keeping the use of the environment variable as it works well for a lot of use cases.

6. For each functional requirement listed in question 5, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.


7. Is there already an existing RFE upstream or in Red Hat bugzilla?

No

8. Does the customer have any specific timeline dependencies?

   Preferably by the end of the year. 

9. Is the sales team involved in this request and do they have any additional input?

No

10. List any affected packages or components.
    spice-client,  rhevm
  .. (may want to get a bit more specific if possible)


11. Would the customer be able to assist in testing this functionality if
implemented?

Yes