1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
|
==================
Horizon Quickstart
==================
Setup
=====
To setup an Horizon development environment simply clone the Horizon git
repository at http://github.com/openstack/horizon and execute the
``run_tests.sh`` script from the root folder (see :doc:`ref/run_tests`).
Horizon assumes a single end-point for OpenStack services which defaults to
the local host (127.0.0.1). If this is not the case change the
``OPENSTACK_HOST`` setting in the ``local_settings.py`` file, located in the
``openstack_dashboard/local`` folder, to the actual IP address of the
OpenStack end-point Horizon should use.
To start the Horizon development server use the Django ``manage.py`` utility
with the context of the virtual environment::
> tools/with_venv.sh ./manage.py runserver
Alternately specify the listen IP and port::
> tools/with_venv.sh ./manage.py runserver 0.0.0.0:8080
Once the Horizon server is running point a web browser to http://localhost:8000
or to the IP and port the server is listening.
.. note::
The ``DevStack`` project (http://devstack.org/) can be used to install
an OpenStack development environment from scratch.
.. 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.
Horizon's Structure
===================
This project is a bit different from other OpenStack projects in that it has
two very distinct components underneath it: ``horizon``, and
``openstack_dashboard``.
The ``horizon`` directory holds the generic libraries and components that can
be used in any Django project.
The ``openstack_dashboard`` directory contains a reference Django project that
uses ``horizon``.
For development, both pieces share an environment which (by default) is
built with the ``tools/install_venv.py`` script. That script creates a
virtualenv and installs all the necessary packages.
If dependencies are added to either ``horizon`` or ``openstack_dashboard``,
they should be added to ``tools/pip-requires``.
.. important::
If you do anything which changes the environment (adding new dependencies
or renaming directories are both great examples) be sure to increment the
``environment_version`` counter in :doc:`run_tests.sh <ref/run_tests>`.
Project
=======
INSTALLED_APPS
--------------
At the project level you add Horizon and any desired dashboards to your
``settings.INSTALLED_APPS``::
INSTALLED_APPS = (
'django',
...
'horizon',
'horizon.dash',
'horizon.syspanel',
)
URLs
----
Then you add a single line to your project's ``urls.py``::
url(r'', include(horizon.urls)),
Those urls are automatically constructed based on the registered Horizon apps.
If a different URL structure is desired it can be constructed by hand.
Templates
---------
Pre-built template tags generate navigation. In your ``nav.html``
template you might have the following::
{% load horizon %}
<div class='nav'>
{% horizon_main_nav %}
</div>
And in your ``sidebar.html`` you might have::
{% load horizon %}
<div class='sidebar'>
{% horizon_dashboard_nav %}
</div>
These template tags are aware of the current "active" dashboard and panel
via template context variables and will render accordingly.
Application
===========
Structure
---------
An application would have the following structure (we'll use syspanel as
an example)::
syspanel/
|---__init__.py
|---dashboard.py <-----Registers the app with Horizon and sets dashboard properties
|---templates/
|---templatetags/
|---overview/
|---services/
|---images/
|---__init__.py
|---panel.py <-----Registers the panel in the app and defines panel properties
|---urls.py
|---views.py
|---forms.py
|---tests.py
|---api.py <-------Optional additional API methods for non-core services
|---templates/
...
...
Dashboard Classes
-----------------
Inside of ``dashboard.py`` you would have a class definition and the registration
process::
import horizon
class Syspanel(horizon.Dashboard):
name = "Syspanel" # Appears in navigation
slug = 'syspanel' # Appears in url
panels = ('overview', 'services', 'instances', 'flavors', 'images',
'tenants', 'users', 'quotas',)
default_panel = 'overview'
roles = ('admin',) # Provides RBAC at the dashboard-level
...
horizon.register(Syspanel)
Panel Classes
-------------
To connect a :class:`~horizon.Panel` with a :class:`~horizon.Dashboard` class
you register it in a ``panels.py`` file like so::
import horizon
from horizon.dashboard.syspanel import dashboard
class Images(horizon.Panel):
name = "Images"
slug = 'images'
roles = ('admin', 'my_other_role',) # Fine-grained RBAC per-panel
# You could also register your panel with another application's dashboard
dashboard.Syspanel.register(Images)
By default a :class:`~horizon.Panel` class looks for a ``urls.py`` file in the
same directory as ``panel.py`` to include in the rollup of url patterns from
panels to dashboards to Horizon, resulting in a wholly extensible, configurable
URL structure.
|
