OpenStack Swift Client Web Interface That Works

Here is an OpenStack Swift Client Web Interface That Works Like Somewhat Rackspace Provides Options For the Clients. It is Python, Django Based. OpenStack, frankly is coded for Rackspaces own usage (obvious, who will develop for the others); where NASA or NSA uses it; that is unknown, but for sure, OpenStack Swift can give solid pain. Understand it – OpenStack is actually nicely coded, but despite it is Free, it is kind of vendor locked, unlike Apache2, Nginx web servers. Rackspace gives everything, but that way of installing OpenStack makes the Clients API dependent. Others install for Key Stone based Authentication. Others mean – IBM, HP etc. HP installed OpenStack a bit wrongly, that actually give some errors. Python is the only way to practically use the power of OpenStack Swift.

Practically, we first published a guide on OpenStack Swift object uploading for the clients in an easy way. You can grep the static objects and upload in modified easy way. It sounds unrealistic, but real development around OpenStack is quite sad. This Python tool has easy web interface that will help to add container meta data and other stuffs. More sadly, most tools are for the Vendor, not the clients. Everyone has http://127.0.0.1:8080/, you have, I have, Rackspace has, HP Cloud has; that kind of URL is for the Vendor, who installed the main instance, kind of bigger version of cPanel.

 

OpenStack Swift Client Web Interface That Works : Basics

 

If you never worked with Python, know the basics; Django for example is very light framework. When we test on local computer, we directly run the App. It sucks so less memory, that you’ll get astonished. It runs as standalone web server. When we run on Server, usually, another web server like Nginx is added as that way of running has small problems.

The software is great but has no documentation. This is the original project :

If you directly install it, the login page will appear, but you actually can not find the settings files, particularly if it is OS X. So, if you edit the core files before running the setup, it will be easier. Python is not PHP – Python has two clear state – working or not working, PHP has nth number of unofficial states – white pages, sucking huge memory etc.

 

OpenStack Swift Client Web Interface That Works : Working With The Existing Project

 

It is better to describe the method for the existing users. We can modify and release it for out of the box Vendor specific usage. Installing the Python Swift-Client is optional. But you need to install tox. Open Terminal (not iTerm2) and run these commands :

If you get Successfully installed tox virtualenv py, Cleaning up... message after any Python web software, it means everything is fine. If you get Storing complete log in /Users/USERNAME/Library/Logs/pip.log, it means the thing has failed to get installed.

Now, you could install that django-swiftbrowser (do not do it) :

In this state, if you run this command :

and open your browser to http://127.0.0.1:8000/; you’ll be able to see this thing :

The person who developed, wrote the README for Microsoft Windows; NOT *nix system. swiftbrowser.settings flag actually incorrect. That has dummy data. Plus the person’s Native Language is German. So, what you’ll do is, if you have installed django-swiftbrowser in that wrong way, uninstall by running :

On OS X, the installation path in that way is :

You will do these :

If you open settings file with nano settings.py, you’ll find :

SWIFT_AUTH_VERSION = 2 will be default, second change with real values. Read our old guide linked in the begining of this guide. That openstack_rc file is important plus your dashboard info. First install django :

That swiftbrowser.settings was not edited. Now, if you run :

settings.py should be adjusted :

More settings :

Option	Default	Description
SWIFT_AUTH_URL	None	The URL for the auth server, e.g. http://127.0.0.1:5000/v2.0
SWIFT_USERNAME	None	The username to use to authenticate.
SWIFT_KEY	None	The key (password) to use to authenticate.
SWIFT_AUTH_VERSION	1	The version of the authentication protocol to use.
SWIFT_TENANT_NAME	None	The tenant name to use when authenticating.
SWIFT_CONTAINER_NAME	None	The container in which to store the files.
SWIFT_STATIC_CONTAINER_NAME	None	Alternate container used by StaticSwiftStorage.
SWIFT_AUTO_CREATE_CONTAINER	False	Should the container be created if it does not exist?
SWIFT_AUTO_BASE_URL	True	Query the authentication server for the base URL.
SWIFT_BASE_URL	None	The base URL from which the files can be retrieved, e.g. http://127.0.0.1:8080/.
SWIFT_USE_TEMP_URLS	False	Generate temporary URLs for file access (allows files to be accessed without a permissive ACL).
SWIFT_TEMP_URL_KEY	None	Temporary URL key — see the OpenStack documentation.
SWIFT_TEMP_URL_DURATION	30*60	How long a temporary URL remains valid, in seconds.
SWIFT_EXTRA_OPTIONS	{}	Extra options, eg. { “endpoint_type”: “adminURL” }, which will return adminURL instead publicURL.

Although it is painful, it is really the best way to specially change the expire headers. Rackspace, basically added these with a nice CSS.