Bug 725032 - [RFE] Support for proxy between conductor back end and cloud provider
Summary: [RFE] Support for proxy between conductor back end and cloud provider
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: deltacloud-core
Version: 1.0.0
Hardware: All
OS: All
high
medium
Target Milestone: rc
Assignee: Michal Fojtik
QA Contact: Ronelle Landy
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-22 15:50 UTC by james labocki
Modified: 2018-12-02 19:08 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-02 12:05:07 UTC


Attachments (Terms of Use)

Description james labocki 2011-07-22 15:50:04 UTC
Description of problem:
This is a RFE to support the use of a proxy server between the conductor back end and cloud provider. Currently, connections to a cloud provider do not support the ability to use a proxy server. In this case, the driver for Amazon EC2 was used.
  
Actual results:
No way to specify a proxy server for use with an Amazon EC2 provider.

Expected results:
Be able to use a proxy server for a provider (Amazon EC2).

Additional info:
I can provide test system for testing if required

Comment 1 Justin Clift 2011-08-12 07:03:43 UTC
Michal Fojtik wrote manual instructions for getting this to work.  This is from his email on the aeolus-devel mailing list (10th August 2011), which doesn't seem to have gotten into the ml archives yet:

  First of all the support for HTTP proxy is not yet pushed into http_connection gem we're using for HTTPS communication with Amazon EC2 API.

  So in order to get it work, you need to install 'manualy' my fork[1] of this gem which has support for 'http_proxy' environment variable. To do that you need:

    $ wget http://mifo.sk/tmp/http_connection-1.4.1.gem
    $ gem uninstall http_connection
    $ gem install http_connection-1.4.1.gem --local

  After that you need to export the 'https_proxy' variable. The best place to do that will be probably the Deltacloud API init.d script (/etc/init.d/deltacloud-core) where you need to put:

    export https_proxy="YOUR_PROXY_ADDRESS:PORT"

  After that, restart deltacloud-core service and you should be able to access EC2 API through proxy.

  I tested the 'http_connection' gem using Squid proxy server with HTTPS and it works well.
  If you run into any problems with this please contact me directly or use the deltacloud-dev@incubator.apache.org mailing list.

Comment 2 Justin Clift 2011-08-12 07:05:59 UTC
Note, the script mentioned above (deltacloud-core) is incorrect for Aeolus 0.3.0, as that is disabled during installation.

For EC2, the correct scripts will be /etc/init.d/deltacloud-ec2*.

Comment 3 Mike Orazi 2011-08-17 16:58:59 UTC
I think we need to discuss how this could work on a per-request basis when we start multiplexing calls through a single deltacloud-core instance.  (We don't necessarily want to use the same proxy values for each provider, etc)

Comment 4 Justin Clift 2011-08-18 03:35:48 UTC
Going with a "proxy per provider" approach may make this difficult to implement.

As a first step, we may want to have a single proxy value (ie "proxy.example.com"), with each provider either using or not using that value (Yes/No).

An example scenario is where:

  + RHEV or VMware running as a private cloud on internal network (doesn't need a proxy)
  + EC2 running as the public cloud (needs a proxy in order to communicate)

For this scenario, the proxy needs to be active for communication with the EC2 provider, but not active for the RHEV or VMware provider.

Proxy support will be required for many corporate environments (at least), so we should be looking to get this into a release sooner rather than later.

Comment 5 Justin Clift 2011-08-18 03:39:02 UTC
It's probably also worth noting that we need SSH communication to go over the proxy as well (ie for EC2 snapshot builds).  This may be achievable via netcat's proxy support.

  https://fedorahosted.org/pipermail/aeolus-devel/2011-August/004200.html

Haven't personally tested it though, and haven't yet heard from the guys here:

Comment 6 wes hayutin 2011-09-28 16:39:01 UTC
making sure all the bugs are at the right version for future queries

Comment 8 Justin Clift 2011-10-21 21:03:52 UTC
Bumping priority, as this will be a complete blocker for customers using a proxy.  (used to be fairly common at least)

Comment 9 wes hayutin 2012-01-12 16:51:10 UTC
adding to sprint tracker

Comment 10 Mike Orazi 2012-01-12 19:52:08 UTC
Is there an updated way to do this, given a multiplexing deltacloud-core?

Comment 11 wes hayutin 2012-02-22 23:45:31 UTC
moving version to 1.0.0 .  version = found in version

Comment 12 Jay Turner 2013-01-10 15:41:02 UTC
Fixing the Version field again . . . version == found in/affected version, not targeted release.


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