Glance with swift backend - upload of an image from horizon is not streaming

Bug #1403129 reported by kanimozhis on 2014-12-16
This bug affects 13 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Timur Sufiev

Bug Description

Glance is configured to use swift as its backend.
While creating image from horizon using image source as image file, the image is uploaded in the controller occupying the disk space of the controller instead of streaming. A tmp file is created in /tmp directory and the owner of this file horizon user.
Image create fails if there is no enough space in controller to hold the full image.
But when the same image is uploaded using glance CLI (from a remote Linux macine) streaming happens as - remote machine to glance to swift.
Streaming also happens in the case of upload using URL from Horizon.
Horizon should stream in the case of image source as image file

kanimozhis (kanimozhis) wrote :
kanimozhis (kanimozhis) wrote :

It is not about cleaning of /tmp directory.
Instead of creating a tmp file, streaming of file data is required as it happens while uploading image from glance CLI.

Timur Sufiev (tsufiev-x) wrote :

Storing uploaded files in /tmp is an inherent property of the Django file-uploading machinery:

While streaming file contents directly to glance would certainly free up some space on controller, it would also raise the question on how to perform form validation in this case.

Changed in horizon:
status: New → Triaged
importance: Undecided → Wishlist
Jyoti Ranjan (jyoti-ranjan) wrote :

The defect directly influence consumption of Horizon for Glance, especially concurrency. If user wants to upload 3 images of large size say 40 GB, he needs to plan for a machine having 120 GB to run horizon. For windows images, 40 GB is common size. Because, all images need to be copied to /tmp directory. For a cloud, 3 concurrent request is very low end and number of concurrent request is likely to be significantly higher.

Considering this aspect, I think that it is a critical defect and streaming functionality is crucial. Otherwise, usage of Glance in horizon will get limited. Or, operator will be forced to use cli which does not look good for Horizon.

Changed in horizon:
assignee: nobody → Nikunj Aggarwal (nikunj2512)
mattfarina (mattfarina) wrote :

This is a problem of scalability and a problem for large uploads, through Horizon, to swift.

I wonder if an easy solution is to change the form so the action points to the API endpoint for glance/swift and have the browser push directly into the service.

Timur Sufiev (tsufiev-x) wrote :

Nikunj, are you working on this? I have one idea regarding this bug that I'd like to check...

Nikunj Aggarwal (nikunj2512) wrote :

Timur, you can say that i am thinking how to solve this problem. But if you have an idea on how to solve it, go head and give it a shot.

Timur Sufiev (tsufiev-x) wrote :

Okay, I'm going to try the luck with the Django Custom Storage

Changed in horizon:
assignee: Nikunj Aggarwal (nikunj2512) → Timur Sufiev (tsufiev-x)
Changed in horizon:
assignee: Timur Sufiev (tsufiev-x) → Vlad Okhrimenko (vokhrimenko)
status: Triaged → In Progress
Timur Sufiev (tsufiev-x) wrote :

Raising to High since it seriously limits the concurrent image upload by different users.

Changed in horizon:
importance: Wishlist → High
assignee: Vlad Okhrimenko (vokhrimenko) → Timur Sufiev (tsufiev-x)
Timur Sufiev (tsufiev-x) wrote :

The patch under work is at

Matthias Runge (mrunge) wrote :

cool, good to know.

Change abandoned by David Lyle (<email address hidden>) on branch: master
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Change abandoned by Timur Sufiev (<email address hidden>) on branch: master
Reason: More lightweight solution is here:

Timur Sufiev (tsufiev-x) wrote :

Update: waiting for Glance team to implement multipart/form-data parser on server-side, to enable 'more lightweight solution' ^^^

Changed in horizon:
assignee: Timur Sufiev (tsufiev-x) → Diana Whitten (hurgleburgler)
Changed in horizon:
assignee: Diana Whitten (hurgleburgler) → Timur Sufiev (tsufiev-x)

Submitter: Jenkins
Branch: master

commit 7e65af5f135a272eed975edd0a797c3bdf086b82
Author: Timur Sufiev <email address hidden>
Date: Thu May 19 18:15:24 2016 +0300

    Embed support for external data sinks into api.glance

    In case 'data' image attribute is a base string (instead of in-memory
    or on-disk file), api.glance sends back an image wrapper with a redirect
    url and a token to its caller, so the caller could upload the file to
    that url directly.

    Provide a unit test for api.glance behavior when an external upload
    location is used. That also requires to fix glance stub endpoint data
    in since it didn't reflect the reality.

    Also document the new HORIZON_IMAGES_UPLOAD_MODE setting that will
    govern direct images upload and the define approach to deprecating the
    old HORIZON_IMAGES_ALLOW_UPLOAD setting. The old setting is deprecated
    as of Newton release and planned to be removed in P. 'Removing' means
    that it will no longer be used / referenced at all in code, not the
    actual presence in (it is removed from in this
    commit). What really matters is if the customized value of
    HORIZON_IMAGES_ALLOW_UPLOAD in will be still
    considered during the deprecation period.

    Help text in Django Create Image form in case if local file upload was
    enabled was wrong, fixed that.

    Related-Bug: #1403129
    Partially implements blueprint: horizon-glance-large-image-upload

    Change-Id: I24ff55e0135514fae89c20175cf9c764e871969b

Submitter: Jenkins
Branch: master

commit 93af461e40fca76eae58066cc1f9de83d7b716ea
Author: Timur Sufiev <email address hidden>
Date: Tue May 17 13:16:15 2016 +0300

    [Django] Allow to upload the image directly to Glance service

    Since large Glance images even temporarily stored on dashboard side
    tend to fill up Web Server filesystem, it is desirable to route image
    payload directly to Glance service (which usually streams it to
    storage backend, which in turn has plenty of space).

    To make it possible we need to trick Django into thinking that a file
    was selected inside FileInput, while its contents are not actually
    transferred to Django server. Then, once image is created client-side
    code needs to know the exact url the image payload needs to be
    transferred to. Both tasks are solved via using ExternalFileField /
    ExternalUploadMeta classes which allow to work around the usual Django
    form processing workflow with minimal changes to CreateImage form
    business logic.

    The client-side code relies on CORS being enabled for Glance service
    (otherwise browser would forbid the PUT request to a location
    different from the one form content came from). In a Devstack setup
    you'll need to edit [cors] section of glance-api.conf file, setting
    `allowed_origin` setting to the full hostname of the web server (say,
    http://<HOST_IP>/dashboard) and restart glance-api process.

    A progress bar is implemented to track the progress of a file upload,
    in case a really huge image is transferred.

    The new machinery could be easily switched on/off with a single
    setting `HORIZON_IMAGES_UPLOAD_MODE` set to 'direct' / 'legacy'.

    Related-Bug: #1467890
    Closes-Bug: #1403129
    Implements blueprint: horizon-glance-large-image-upload
    Change-Id: I01d02f75268186b43066df6fd966aa01c08e01d7

Changed in horizon:
status: In Progress → Fix Released

This issue was fixed in the openstack/horizon development milestone.

SUYASH KARMARKAR (skarmarkar) wrote :

Is there a workaround to get past this issue till we have a fix?

Timur Sufiev (tsufiev-x) wrote :

Yes, disable the local file upload in Create Image is the well-known workaround for this issue :).

Hi Suyash

Did you get he workaround ? If yes then please share.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers