blob: a4d940d7623678190e56c1e23355b1de78653362 [file] [log] [blame]
Dean Troyer0986a7b2014-10-29 22:08:13 -05001=============
2Configuration
3=============
Sean M. Collins09e550c2014-10-21 11:40:08 -04004
5DevStack has always tried to be mostly-functional with a minimal amount
6of configuration. The number of options has ballooned as projects add
7features, new projects added and more combinations need to be tested.
8Historically DevStack obtained all local configuration and
9customizations from a ``localrc`` file. The number of configuration
10variables that are simply passed-through to the individual project
11configuration files is also increasing. The old mechanism for this
12(``EXTRAS_OPTS`` and friends) required specific code for each file and
13did not scale well.
14
15In Oct 2013 a new configuration method was introduced (in `review
1646768 <https://review.openstack.org/#/c/46768/>`__) to hopefully
17simplify this process and meet the following goals:
18
19- contain all non-default local configuration in a single file
20- be backward-compatible with ``localrc`` to smooth the transition
21 process
22- allow settings in arbitrary configuration files to be changed
23
24local.conf
25~~~~~~~~~~
26
27The new configuration file is ``local.conf`` and resides in the root
28DevStack directory like the old ``localrc`` file. It is a modified INI
29format file that introduces a meta-section header to carry additional
30information regarding the configuration files to be changed.
31
32The new header is similar to a normal INI section header but with double
33brackets (``[[ ... ]]``) and two internal fields separated by a pipe
34(``|``):
35
36::
37
38 [[ <phase> | <config-file-name> ]]
39
40where ``<phase>`` is one of a set of phase names defined by ``stack.sh``
41and ``<config-file-name>`` is the configuration filename. The filename
42is eval'ed in the ``stack.sh`` context so all environment variables are
43available and may be used. Using the project config file variables in
44the header is strongly suggested (see the ``NOVA_CONF`` example below).
45If the path of the config file does not exist it is skipped.
46
47The defined phases are:
48
49- **local** - extracts ``localrc`` from ``local.conf`` before
50 ``stackrc`` is sourced
51- **pre-install** - runs after the system packages are installed but
52 before any of the source repositories are installed
53- **install** - runs immediately after the repo installations are
54 complete
55- **post-config** - runs after the layer 2 services are configured and
56 before they are started
57- **extra** - runs after services are started and before any files in
58 ``extra.d`` are executed
59
60The file is processed strictly in sequence; meta-sections may be
61specified more than once but if any settings are duplicated the last to
62appear in the file will be used.
63
64::
65
66 [[post-config|$NOVA_CONF]]
67 [DEFAULT]
68 use_syslog = True
69
70 [osapi_v3]
71 enabled = False
72
73A specific meta-section ``local|localrc`` is used to provide a default
74``localrc`` file (actually ``.localrc.auto``). This allows all custom
75settings for DevStack to be contained in a single file. If ``localrc``
76exists it will be used instead to preserve backward-compatibility. More
Dean Troyerea3cdfa2014-11-08 08:29:16 -060077details on the :doc:`contents of local.conf <local.conf>` are available.
Sean M. Collins09e550c2014-10-21 11:40:08 -040078
79::
80
81 [[local|localrc]]
82 FIXED_RANGE=10.254.1.0/24
83 ADMIN_PASSWORD=speciale
84 LOGFILE=$DEST/logs/stack.sh.log
85
86Note that ``Q_PLUGIN_CONF_FILE`` is unique in that it is assumed to
87*NOT* start with a ``/`` (slash) character. A slash will need to be
88added:
89
90::
91
92 [[post-config|/$Q_PLUGIN_CONF_FILE]]
93
94Also note that the ``localrc`` section is sourced as a shell script
95fragment amd MUST conform to the shell requirements, specifically no
96whitespace around ``=`` (equals).
97
98Minimal Configuration
99~~~~~~~~~~~~~~~~~~~~~
100
101While ``stack.sh`` is happy to run without a ``localrc`` section in
102``local.conf``, devlife is better when there are a few minimal variables
103set. This is an example of a minimal configuration that touches the
104values that most often need to be set.
105
106- no logging
107- pre-set the passwords to prevent interactive prompts
108- move network ranges away from the local network (``FIXED_RANGE`` and
109 ``FLOATING_RANGE``, commented out below)
110- set the host IP if detection is unreliable (``HOST_IP``, commented
111 out below)
112
113::
114
115 [[local|localrc]]
116 ADMIN_PASSWORD=secrete
117 DATABASE_PASSWORD=$ADMIN_PASSWORD
118 RABBIT_PASSWORD=$ADMIN_PASSWORD
119 SERVICE_PASSWORD=$ADMIN_PASSWORD
120 SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
121 #FIXED_RANGE=172.31.1.0/24
122 #FLOATING_RANGE=192.168.20.0/25
123 #HOST_IP=10.3.4.5
124
125If the ``*_PASSWORD`` variables are not set here you will be prompted to
126enter values for them by ``stack.sh``.
127
128The network ranges must not overlap with any networks in use on the
129host. Overlap is not uncommon as RFC-1918 'private' ranges are commonly
130used for both the local networking and Nova's fixed and floating ranges.
131
132``HOST_IP`` is normally detected on the first run of ``stack.sh`` but
133often is indeterminate on later runs due to the IP being moved from an
134Ethernet integace to a bridge on the host. Setting it here also makes it
135available for ``openrc`` to set ``OS_AUTH_URL``. ``HOST_IP`` is not set
136by default.
137
138Common Configuration Variables
139~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
140
141Set DevStack install directory
142 | *Default: ``DEST=/opt/stack``*
143 | The DevStack install directory is set by the ``DEST`` variable.
144 | By setting it early in the ``localrc`` section you can reference it
145 in later variables. It can be useful to set it even though it is not
146 changed from the default value.
147 |
148
149 ::
150
151 DEST=/opt/stack
152
153stack.sh logging
154 | *Defaults: ``LOGFILE="" LOGDAYS=7 LOG_COLOR=True``*
155 | By default ``stack.sh`` output is only written to the console
156 where is runs. It can be sent to a file in addition to the console
157 by setting ``LOGFILE`` to the fully-qualified name of the
158 destination log file. A timestamp will be appended to the given
159 filename for each run of ``stack.sh``.
160 |
161
162 ::
163
164 LOGFILE=$DEST/logs/stack.sh.log
165
166 Old log files are cleaned automatically if ``LOGDAYS`` is set to the
167 number of days of old log files to keep.
168
169 ::
170
171 LOGDAYS=1
172
173 The some of the project logs (Nova, Cinder, etc) will be colorized
174 by default (if ``SYSLOG`` is not set below); this can be turned off
175 by setting ``LOG_COLOR`` False.
176
177 ::
178
179 LOG_COLOR=False
180
181Screen logging
182 | *Default: ``SCREEN_LOGDIR=""``*
183 | By default DevStack runs the OpenStack services using ``screen``
184 which is useful for watching log and debug output. However, in
185 automated testing the interactive ``screen`` sessions may not be
186 available after the fact; setting ``SCREEN_LOGDIR`` enables logging
187 of the ``screen`` sessions in the specified diretory. There will be
188 one file per ``screen`` session named for the session name and a
189 timestamp.
190 |
191
192 ::
193
194 SCREEN_LOGDIR=$DEST/logs/screen
195
196 *Note the use of ``DEST`` to locate the main install directory; this
197 is why we suggest setting it in ``local.conf``.*
198
199One syslog to bind them all
200 | *Default: ``SYSLOG=False SYSLOG_HOST=$HOST_IP SYSLOG_PORT=516``*
201 | Logging all services to a single syslog can be convenient. Enable
202 syslogging by setting ``SYSLOG`` to ``True``. If the destination log
203 host is not localhost ``SYSLOG_HOST`` and ``SYSLOG_PORT`` can be
204 used to direct the message stream to the log host.
205 |
206
207 ::
208
209 SYSLOG=True
210 SYSLOG_HOST=$HOST_IP
211 SYSLOG_PORT=516
212
213A clean install every time
214 | *Default: ``RECLONE=""``*
215 | By default ``stack.sh`` only clones the project repos if they do
216 not exist in ``$DEST``. ``stack.sh`` will freshen each repo on each
217 run if ``RECLONE`` is set to ``yes``. This avoids having to manually
218 remove repos in order to get the current branch from ``$GIT_BASE``.
219 |
220
221 ::
222
223 RECLONE=yes
224
225 Swift
226 Default: SWIFT_HASH="" SWIFT_REPLICAS=1 SWIFT_DATA_DIR=$DEST/data/swift
227 Swift is now used as the back-end for the S3-like object store. When enabled Nova's objectstore (n-obj in ENABLED_SERVICES) is automatically disabled. Enable Swift by adding it services to ENABLED_SERVICES:
228 enable_service s-proxy s-object s-container s-account
229
230 Setting Swift's hash value is required and you will be prompted for
231 it if Swift is enabled so just set it to something already:
232
233 ::
234
235 SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5
236
237 For development purposes the default number of replicas is set to
238 ``1`` to reduce the overhead required. To better simulate a
239 production deployment set this to ``3`` or more.
240
241 ::
242
243 SWIFT_REPLICAS=3
244
245 The data for Swift is stored in the source tree by default (in
246 ``$DEST/swift/data``) and can be moved by setting
247 ``SWIFT_DATA_DIR``. The specified directory will be created if it
248 does not exist.
249
250 ::
251
252 SWIFT_DATA_DIR=$DEST/data/swift
253
254 *Note: Previously just enabling ``swift`` was sufficient to start
255 the Swift services. That does not provide proper service
256 granularity, particularly in multi-host configurations, and is
257 considered deprecated. Some service combination tests now check for
258 specific Swift services and the old blanket acceptance will longer
259 work correctly.*
260
261Service Catalog Backend
262 | *Default: ``KEYSTONE_CATALOG_BACKEND=sql``*
263 | DevStack uses Keystone's ``sql`` service catalog backend. An
264 alternate ``template`` backend is also available. However, it does
265 not support the ``service-*`` and ``endpoint-*`` commands of the
266 ``keystone`` CLI. To do so requires the ``sql`` backend be enabled:
267 |
268
269 ::
270
271 KEYSTONE_CATALOG_BACKEND=template
272
273 DevStack's default configuration in ``sql`` mode is set in
274 ``files/keystone_data.sh``
275
276Cinder
277 | Default:
278 | VOLUME_GROUP="stack-volumes" VOLUME_NAME_PREFIX="volume-" VOLUME_BACKING_FILE_SIZE=10250M
279 | The logical volume group used to hold the Cinder-managed volumes
280 is set by ``VOLUME_GROUP``, the logical volume name prefix is set
281 with ``VOLUME_NAME_PREFIX`` and the size of the volume backing file
282 is set with ``VOLUME_BACKING_FILE_SIZE``.
283 |
284
285 ::
286
287 VOLUME_GROUP="stack-volumes"
288 VOLUME_NAME_PREFIX="volume-"
289 VOLUME_BACKING_FILE_SIZE=10250M
290
291Multi-host DevStack
292 | *Default: ``MULTI_HOST=False``*
293 | Running DevStack with multiple hosts requires a custom
294 ``local.conf`` section for each host. The master is the same as a
295 single host installation with ``MULTI_HOST=True``. The slaves have
296 fewer services enabled and a couple of host variables pointing to
297 the master.
298 | **Master**
299
300 ::
301
302 MULTI_HOST=True
303
304 **Slave**
305
306 ::
307
308 MYSQL_HOST=w.x.y.z
309 RABBIT_HOST=w.x.y.z
310 GLANCE_HOSTPORT=w.x.y.z:9292
311 ENABLED_SERVICES=n-vol,n-cpu,n-net,n-api
312
313API rate limits
314 | Default: ``API_RATE_LIMIT=True``
315 | Integration tests such as Tempest will likely run afoul of the
316 default rate limits configured for Nova. Turn off rate limiting
317 during testing by setting ``API_RATE_LIMIT=False``.*
318 |
319
320 ::
321
322 API_RATE_LIMIT=False
323
324Examples
325~~~~~~~~
326
327- Eliminate a Cinder pass-through (``CINDER_PERIODIC_INTERVAL``):
328
329 ::
330
331 [[post-config|$CINDER_CONF]]
332 [DEFAULT]
333 periodic_interval = 60
334
335- Sample ``local.conf`` with screen logging enabled:
336
337 ::
338
339 [[local|localrc]]
340 FIXED_RANGE=10.254.1.0/24
341 NETWORK_GATEWAY=10.254.1.1
342 LOGDAYS=1
343 LOGFILE=$DEST/logs/stack.sh.log
344 SCREEN_LOGDIR=$DEST/logs/screen
345 ADMIN_PASSWORD=quiet
346 DATABASE_PASSWORD=$ADMIN_PASSWORD
347 RABBIT_PASSWORD=$ADMIN_PASSWORD
348 SERVICE_PASSWORD=$ADMIN_PASSWORD
349 SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50