openstack/horizon
Code Issues Proposed changes
OpenStack Dashboard (Horizon)
4,941 Commits 10 Branches 54 Tags 311 MiB
Python 63.1%
JavaScript 28.8%
HTML 6.5%
SCSS 1.5%
fa7105d0da
Go to file
Gloria Gu fa7105d0da Enable changing volume type of a volume 
Expose the functionality of the 'cinder retype' command in the UI.
It allows user to change the volume type of a volume whose status is
in-use or available when horizon's cinder API version is >= 2.

cinder retype is only supported starting cinder v2.

If enabled_backends is specified in /etc/cinder/cinder.conf,
retype is actually performed by a specific driver.
It depends on the drivers (backends) that are associated
with volume types.
Volume types are set through type-key extra specs.

If enabled_backends in cinder.conf is not specified, volumes are
created by LVM so retype is actually performaned in LVM.

During retype, if cinder finds it can not retype, it will check
if the migration policy is on_demand or never. If the policy is
is never, then cinder does not do anything, otherwise, it will
perform migration. By default, in the horizon retype dialog UI,
migration policy is never which is also the default
of the cinder cli command.

Currently in horizon cinder api default version is 1. In order to
test this functionallity, you need to update
openstack_dashboard/local/local_settings.py to have the "volume"
API to use version 2 so the "Change Volume Type" action menu
shows up for the volume. If local_settings.py is not available, you
need to copy the local_settings.py.example file, change it to
local_settings.py, update other necessary settings and also update
have the API version setting like the followings:

OPENSTACK_API_VERSIONS = {
    #"data_processing": 1.1,
    #"identity": 3,
    "volume": 2
}

Implements: blueprint volume-retype

Change-Id: Id8bc539e1849f5910df34d7b76cc250ec82f9671
2014-08-25 11:09:31 -07:00
.tx Update .tx/config with type of files 2014-03-21 15:30:03 +01:00
doc Add instructions for packaging JS libs 2014-08-22 13:18:33 +02:00
horizon Importing with_statement from __future__ is useless 2014-08-24 20:59:45 +02:00
openstack_dashboard Enable changing volume type of a volume 2014-08-25 11:09:31 -07:00
tools Remove requirements style check 2014-07-08 09:50:14 -07:00
.gitignore Created a make_web_conf command. 2014-04-03 17:34:32 +02:00
.gitreview Add .gitreview and rfc.sh. 2011-10-28 09:50:35 -04:00
.mailmap Update my mailmap 2013-10-25 14:49:23 +08:00
.pylintrc updating run_tests.sh to mimic other openstack projects, pep8, pylint, coverage 2011-08-31 14:41:36 -07:00
CONTRIBUTING.rst Add CONTRIBUTING.rst 2014-07-09 14:47:57 +08:00
HACKING.rst Replace force_unicode with force_text 2014-08-06 14:34:53 +02:00
LICENSE Initial commit 2011-01-12 13:43:31 -08:00
Makefile Unifies the project packaging into one set of modules. 2012-02-29 00:20:13 -08:00
manage.py Gate on H102 Apache 2.0 license header not found for pep8 2013-11-19 13:55:04 -05:00
MANIFEST.in Drop NodeJS dependency in favor of pure-python lesscpy 2013-08-16 09:31:08 +02:00
openstack-common.conf Synced jsonutils from oslo-incubator 2014-05-27 12:25:45 +02:00
README.rst Fix build instructions and formatting in README 2014-05-09 18:22:50 +00:00
requirements.txt Unbundle all JavaScript libraries from Horizon 2014-08-19 09:59:12 +02:00
run_tests.sh Merge "Provide a quick way to run flake8" 2014-08-25 07:52:25 +00:00
setup.cfg Open Juno development 2014-03-31 10:32:44 +02:00
setup.py Updated from global requirements 2014-05-01 13:44:26 +00:00
test-requirements.txt Updated from global requirements 2014-08-22 23:29:29 +00:00
tox.ini Exclude .ropeproject from flake8 checks 2014-08-22 11:23:17 -07:00

README.rst

Horizon (OpenStack Dashboard)

Horizon is a Django-based project aimed at providing a complete OpenStack Dashboard along with an extensible framework for building new dashboards from reusable components. The openstack_dashboard module is a reference implementation of a Django site that uses the horizon app to provide web-based interactions with the various OpenStack projects.

For release management:

For blueprints and feature specifications:

For issue tracking:

Getting Started

For local development, first create a virtualenv for the project. In the tools directory there is a script to create one for you:

$ python tools/install_venv.py

Alternatively, the run_tests.sh script will also install the environment for you and then run the full test suite to verify everything is installed and functioning correctly.

Now that the virtualenv is created, you need to configure your local environment. To do this, create a local_settings.py file in the openstack_dashboard/local/ directory. There is a local_settings.py.example file there that may be used as a template.

If all is well you should able to run the development server locally:

$ tools/with_venv.sh ./manage.py runserver

or, as a shortcut:

$ ./run_tests.sh --runserver

Setting Up OpenStack

The recommended tool for installing and configuring the core OpenStack components is Devstack. Refer to their documentation for getting Nova, Keystone, Glance, etc. up and running.

Note

The minimum required set of OpenStack services running includes the following:

  • Nova (compute, api, scheduler, network, and volume services)
  • Glance
  • Keystone

Optional support is provided for Swift.

Development

For development, start with the getting started instructions above. Once you have a working virtualenv and all the necessary packages, read on.

If dependencies are added to either horizon or openstack_dashboard, they should be added to requirements.txt.

The run_tests.sh script invokes tests and analyses on both of these components in its process, and it is what Jenkins uses to verify the stability of the project. If run before an environment is set up, it will ask if you wish to install one.

To run the unit tests:

$ ./run_tests.sh

Building Contributor Documentation

This documentation is written by contributors, for contributors.

The source is maintained in the doc/source directory using reStructuredText and built by Sphinx

  • Building Automatically:

    $ ./run_tests.sh --docs

  • Building Manually:

    $ tools/with_venv.sh sphinx-build doc/source doc/build/html

Results are in the doc/build/html directory