Bug 725032

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.org mailing list.

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

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)

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.

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:

making sure all the bugs are at the right version for future queries

Bumping priority, as this will be a complete blocker for customers using a proxy.  (used to be fairly common at least)

adding to sprint tracker

Is there an updated way to do this, given a multiplexing deltacloud-core?

moving version to 1.0.0 .  version = found in version

Fixing the Version field again . . . version == found in/affected version, not targeted release.