695bf560c0
blueprint quantum-security-group Rule table view * Add direction and ethertype columns (which are specific to Neutron) It may be better to hide "Direction" and "Ether Type" columns unless Quantum security group is enabled. * Merge ip_protocol/from_port/to_port into one column for better view * Use "::/0" for IPv6 ANY instead of "0.0.0.0/0" * Rename "Source" column to "Remote". (The naming "source" does not fit egress rules) * Display security group name in the title of rule detail view Rule creation form * New arguments 'direction' and 'ethertype' in security_group_rule_create() * Set the default value of 'direction' to 'ingress' in forms.handle() * Rename 'ip_protocol' to 'rule_menu' and 'source' to 'remote' Note that rule_menu is retrieved from rule.ip_protocol in the unit tests since they are tests for custom TCP/UDP/ICMP rules. Network abstraction layer for security group management * Move security group methods to api.network * Add Neutron security group API implementation * Move base classes for network abstraction to a separate module (api/network_base.py) to avoid circulated import between api.network and api.nova/api.neutron Add a configuration parameter to control Neutron security group support * Neutron security group support is enabled when Neutron is enabled and enable_security_group in OPENSTACK_NEUTRON_NETWORK in settings is True. * Not all neutron plugins support security group, so we need a way to control neutron security group is enabled or not. * It can be determined by supported extension list from Neutron and it is a possible future work. Move get_int_or_uuid to openstack_dashboard/utils/filters. * get_int_or_uuid is now used in security_group implementation as well as floating IP logics. * In addition the depth of the directory tree becomes longer and it is hard to fit the import line in 80 chars. It is a good chance to move it to a common directory. Add __repr__ to API**Wrapper to make it easier to debug. Limitations: Neutron supports per-port security group. security groups can be associated with a port instead of an instace and each port can have a different set of security groups. It is not a scope of this BP and is a future work. Change-Id: I5410e88043a364596037b9ebcc566cd50b317614
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:
Dependencies
To get started you will need to install Node.js (http://nodejs.org/) on your machine. Node.js is used with Horizon in order to use LESS (http://lesscss.org/) for our CSS needs. Horizon is currently using Node.js v0.6.12.
For Ubuntu use apt to install Node.js:
$ sudo apt-get install nodejsFor other versions of Linux, please see here:: http://nodejs.org/#download for how to install Node.js on your system.
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 --runserverSettings 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.shBuilding Contributor Documentation
This documentation is written by contributors, for contributors.
The source is maintained in the doc/source folder using
reStructuredText
and built by Sphinx
Building Automatically:
$ ./run_tests.sh --docsBuilding Manually:
$ export DJANGO_SETTINGS_MODULE=local.local_settings $ python doc/generate_autodoc_index.py $ sphinx-build -b html doc/source build/sphinx/html
Results are in the build/sphinx/html directory