Bug 731420 - [RFE] Image Factory does not work behind a proxy
Summary: [RFE] Image Factory does not work behind a proxy
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: imagefactory
Version: 1.0.0
Hardware: x86_64
OS: Linux
Target Milestone: 1.1.3
Assignee: Ian McLeod
QA Contact: Rehana
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-17 15:27 UTC by Berthault
Modified: 2020-03-27 19:07 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2020-03-27 19:07:16 UTC

Attachments (Terms of Use)

Description Berthault 2011-08-17 15:27:24 UTC
Description of problem:
"aeolus-image push" command to Amazon EC2 is KO because of an exception in image-factory.

All our systems are behind a proxy. Without a doubt, the problem comes from this proxy but we can't bypassed it.

The environment variables http_proxy and https_proxy have been added in the deltacloud-core, deltacloud-ec2-us-east-1, deltacloud-ec2-us-west-1, imagefactory and iwhd daemons. But the problem already exists.

Version-Release number of selected component (if applicable):

How reproducible:
Use Aeolus behind a proxy.

Steps to Reproduce:
Actual results:
[root]# aeolus-image push -r ec2-us-east-1 --id 864dad40-cf9b-44c2-ae84-962d64bb8996
    Provider Image: c76732dd-7a64-4074-87b0-8983cf3dae9a
    Image: 864dad40-cf9b-44c2-ae84-962d64bb8996
    Build: ad4b8caa-f3d4-4f42-8fd4-968b67e3c4e5
    Status: FAILED
    Percent Complete: 0

[root]# cat /var/log/imagefactory.log
    2011-08-17 15:38:13,752 DEBUG imagefactory.qmfagent.ImageFactoryAgent.ImageFactoryAgent pid(2290)
        Method called: name = push_image
        args = {'credentials': '*** REDACTED ***', 'image': '864dad40-cf9b-44c2-ae84-962d64bb8996', 'build': '', 'providers': ['ec2-us-east-1']}
        handle = <cqmf2.AgentEvent; proxy of <Swig Object of type 'qmf::AgentEvent *' at 0x2c89030> >
        addr = redhat.com:imagefactory:3aa62164-8dc2-46a0-b896-213bc16649da:image_factory
        subtypes = {}
        userId = anonymous
    2011-08-17 15:38:13,753 DEBUG imagefactory.ImageWarehouse.ImageWarehouse pid(2290)
        Created Image Warehouse instance http://localhost:9090 - buckets(target_images, templates, icicles, provider_images)
        Getting metadata (['latest_unpushed']) from http://localhost:9090/images/864dad40-cf9b-44c2-ae84-962d64bb8996
        Querying (http://localhost:9090/target_images/_query)
                 with expression ($build == "ad4b8caa-f3d4-4f42-8fd4-968b67e3c4e5" && $target == "ec2")
        Getting metadata (['template']) from http://localhost:9090/target_images/7756b621-4543-42f7-bcf1-e9326f5b5f20
        Created Image Warehouse instance http://localhost:9090 - buckets(target_images, templates, icicles, provider_images)
        Created Image Warehouse instance http://localhost:9090 - buckets(target_images, templates, icicles, provider_images)
    2011-08-17 15:38:13,771 DEBUG oz.Guest.FedoraRemoteGuest pid(2290)
        Name: Fedora 14 x86_64 with updates-c76732dd-7a64-4074-87b0-8983cf3dae9a,
              UUID: a9344787-30a9-492f-8dbc-819b55a47e08
        MAC: 52:54:00:f3:60:d6, distro: Fedora
        update: 14, arch: x86_64, diskimage: /var/tmp/Fedora 14 x86_64
                with updates-c76732dd-7a64-4074-87b0-8983cf3dae9a.dsk
        nicmodel: virtio, clockoffset: utc
        mousetype: ps2, disk_bus: virtio, disk_dev: vda
        icicletmp: /var/lib/oz/icicletmp/Fedora 14 x86_64
                   with updates-c76732dd-7a64-4074-87b0-8983cf3dae9a, listen_port: 29311
        Original ISO path: /var/lib/oz/isos/Fedora14x86_64-url.iso
        Modified ISO cache: /var/lib/oz/isos/Fedora14x86_64-url-oz.iso
        Output ISO path: /var/tmp/Fedora 14 x86_64
                         with updates-c76732dd-7a64-4074-87b0-8983cf3dae9a-url-oz.iso
        ISO content path: /var/lib/oz/isocontent/Fedora 14 x86_64
                          with updates-c76732dd-7a64-4074-87b0-8983cf3dae9a-url
    2011-08-17 15:38:13,776 DEBUG imagefactory.builders.BaseBuilder.FedoraBuilder pid(2290)
        Exception caught in ImageFactory
        Traceback (most recent call last):
        File "/usr/lib/python2.7/site-packages/imagefactory/builders/FedoraBuilder.py", line 498, in push_image
        File "/usr/lib64/python2.7/urllib2.py", line 1173, in http_open
            return self.do_open(httplib.HTTPConnection, req)
        File "/usr/lib64/python2.7/urllib2.py", line 1148, in do_open
            raise URLError(err)
        URLError: <urlopen error [Errno -2] Name or service not known>
    2011-08-17 15:38:13,807 DEBUG imagefactory.BuildJob.BuildAdaptor pid(2290)
        Raising event with agent handler (<ImageFactoryAgent(Thread-1, initial)>),
        changed status from NEW to FAILED

Expected results:

Additional info:

Comment 1 wes hayutin 2011-08-17 16:33:37 UTC
If the issue is only w/ a proxy env.. this probably should be closed as a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=725032

Comment 2 Mike Orazi 2011-08-17 17:01:33 UTC
725032 talks about deltacloud-core being able to honor proxy settings, this talks about imagefactory.  I'd suggest we investigate each one individually for now.  We can always close as dupe later.

Comment 3 Steve Loranz 2011-08-17 17:56:30 UTC
This was already in the backlog for image factory features and is currently being considered as a candidate feature of image factory 0.6.0.  https://www.aeolusproject.org/redmine/issues/2105

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

Comment 6 wes hayutin 2012-01-12 16:51:43 UTC
adding to sprint tracker

Comment 7 jrd 2012-01-13 15:22:49 UTC
There's no way this will happen in 1.0.  Moving to 1.1.

Comment 8 Mitch 2012-01-18 15:14:51 UTC
After speaking with JRD about this the past few days, I think the 'fix', for now, is for the admin to manually build their snapshot in EC2 directly and then import the image into CF for management.  They can launch instances from there when needed.  We still need to address the katello issues behind a proxy, but I'll speak to that team and give them a heads up.


Comment 9 wes hayutin 2012-02-22 23:46:02 UTC
moving version to 1.0.0 .  version = found in version

Comment 10 Hugh Brock 2012-05-07 18:04:52 UTC
Right answer for this is remote factory, which is probably 2.0 but I'll leave this open for 1.1.

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