Do the link cleanups and update a handful of things that were
out of date.
Change-Id: I758027bf3577c66cfb13df963516823a5c247080
... | ... |
@@ -74,7 +74,7 @@ A specific meta-section ``local|localrc`` is used to provide a default |
74 | 74 |
``localrc`` file (actually ``.localrc.auto``). This allows all custom |
75 | 75 |
settings for DevStack to be contained in a single file. If ``localrc`` |
76 | 76 |
exists it will be used instead to preserve backward-compatibility. More |
77 |
-details on the `contents of localrc <localrc.html>`__ are available. |
|
77 |
+details on the :doc:`contents of local.conf <local.conf>` are available. |
|
78 | 78 |
|
79 | 79 |
:: |
80 | 80 |
|
... | ... |
@@ -59,16 +59,17 @@ Code |
59 | 59 |
The DevStack repo generally keeps all of the primary scripts at the root |
60 | 60 |
level. |
61 | 61 |
|
62 |
-``docs`` - Contains the source for this website. It is built using |
|
63 |
-``tools/build_docs.sh``. |
|
62 |
+``doc`` - Contains the Sphinx source for the documentation. |
|
63 |
+``tools/build_docs.sh`` is used to generate the HTML versions of the |
|
64 |
+DevStack scripts. A complete doc build can be run with ``tox -edocs``. |
|
64 | 65 |
|
65 |
-``exercises`` - Contains the test scripts used to validate and |
|
66 |
+``exercises`` - Contains the test scripts used to sanity-check and |
|
66 | 67 |
demonstrate some OpenStack functions. These scripts know how to exit |
67 | 68 |
early or skip services that are not enabled. |
68 | 69 |
|
69 | 70 |
``extras.d`` - Contains the dispatch scripts called by the hooks in |
70 |
-``stack.sh``, ``unstack.sh`` and ``clean.sh``. See `the plugins |
|
71 |
-docs <plugins.html>`__ for more information. |
|
71 |
+``stack.sh``, ``unstack.sh`` and ``clean.sh``. See :doc:`the plugins |
|
72 |
+docs <plugins>` for more information. |
|
72 | 73 |
|
73 | 74 |
``files`` - Contains a variety of otherwise lost files used in |
74 | 75 |
configuring and operating DevStack. This includes templates for |
... | ... |
@@ -84,10 +85,10 @@ there are some for system services and project plugins. |
84 | 84 |
DevStack repo. |
85 | 85 |
|
86 | 86 |
``tests`` - the DevStack test suite is rather sparse, mostly consisting |
87 |
-of test of specific fragile functions in the ``functions`` file. |
|
87 |
+of test of specific fragile functions in the ``functions`` and |
|
88 |
+``functions-common`` files. |
|
88 | 89 |
|
89 |
-``tools`` - Contains a collection of stand-alone scripts, some of which |
|
90 |
-have aged a bit (does anyone still do ramdisk installs?). While these |
|
90 |
+``tools`` - Contains a collection of stand-alone scripts. While these |
|
91 | 91 |
may reference the top-level DevStack configuration they can generally be |
92 | 92 |
run alone. There are also some sub-directories to support specific |
93 | 93 |
environments such as XenServer. |
... | ... |
@@ -47,11 +47,8 @@ Q: I'd like to help! |
47 | 47 |
and bug reports go to |
48 | 48 |
`LaunchPad <http://bugs.launchpad.net/devstack/>`__. Contributions |
49 | 49 |
follow the usual process as described in the `OpenStack |
50 |
- wiki <http://wiki.openstack.org/HowToContribute>`__ even though |
|
51 |
- DevStack is not an official OpenStack project. This site is housed |
|
52 |
- in the CloudBuilder's |
|
53 |
- `github <http://github.com/cloudbuilders/devstack>`__ in the |
|
54 |
- gh-pages branch. |
|
50 |
+ wiki <http://wiki.openstack.org/HowToContribute>`__. This Sphinx |
|
51 |
+ documentation is housed in the doc directory. |
|
55 | 52 |
Q: Why not use packages? |
56 | 53 |
A: Unlike packages, DevStack leaves your cloud ready to develop - |
57 | 54 |
checkouts of the code and services running in screen. However, many |
... | ... |
@@ -16,9 +16,9 @@ download the `Minimal |
16 | 16 |
CD <https://help.ubuntu.com/community/Installation/MinimalCD>`__ for |
17 | 17 |
Ubuntu releases since DevStack will download & install all the |
18 | 18 |
additional dependencies. The netinstall ISO is available for |
19 |
-`Fedora <http://mirrors.kernel.org/fedora/releases/18/Fedora/x86_64/iso/Fedora-20-x86_64-netinst.iso>`__ |
|
19 |
+`Fedora <http://mirrors.kernel.org/fedora/releases/>`__ |
|
20 | 20 |
and |
21 |
-`CentOS/RHEL <http://mirrors.kernel.org/centos/6.5/isos/x86_64/CentOS-6.5-x86_64-netinstall.iso>`__. |
|
21 |
+`CentOS/RHEL <http://mirrors.kernel.org/centos/>`__. |
|
22 | 22 |
|
23 | 23 |
Install a couple of packages to bootstrap configuration: |
24 | 24 |
|
... | ... |
@@ -284,7 +284,7 @@ Volumes |
284 | 284 |
|
285 | 285 |
DevStack will automatically use an existing LVM volume group named |
286 | 286 |
``stack-volumes`` to store cloud-created volumes. If ``stack-volumes`` |
287 |
-doesn't exist, DevStack will set up a 5Gb loop-mounted file to contain |
|
287 |
+doesn't exist, DevStack will set up a 10Gb loop-mounted file to contain |
|
288 | 288 |
it. This obviously limits the number and size of volumes that can be |
289 | 289 |
created inside OpenStack. The size can be overridden by setting |
290 | 290 |
``VOLUME_BACKING_FILE_SIZE`` in ``local.conf``. |
... | ... |
@@ -17,9 +17,9 @@ download the `Minimal |
17 | 17 |
CD <https://help.ubuntu.com/community/Installation/MinimalCD>`__ for |
18 | 18 |
Ubuntu releases since DevStack will download & install all the |
19 | 19 |
additional dependencies. The netinstall ISO is available for |
20 |
-`Fedora <http://mirrors.kernel.org/fedora/releases/18/Fedora/x86_64/iso/Fedora-20-x86_64-netinst.iso>`__ |
|
20 |
+`Fedora <http://mirrors.kernel.org/fedora/releases/>`__ |
|
21 | 21 |
and |
22 |
-`CentOS/RHEL <http://mirrors.kernel.org/centos/6.5/isos/x86_64/CentOS-6.5-x86_64-netinstall.iso>`__. |
|
22 |
+`CentOS/RHEL <http://mirrors.kernel.org/centos/>`__. |
|
23 | 23 |
You may be tempted to use a desktop distro on a laptop, it will probably |
24 | 24 |
work but you may need to tell Network Manager to keep its fingers off |
25 | 25 |
the interface(s) that OpenStack uses for bridging. |
... | ... |
@@ -4,6 +4,6 @@ local.conf - User Settings |
4 | 4 |
|
5 | 5 |
``local.conf`` is a user-maintained setings file that is sourced in |
6 | 6 |
``stackrc``. It contains a section that replaces the historical |
7 |
-``localrc`` file. See `the description of |
|
8 |
-local.conf <configuration.html>`__ for more details about the mechanics |
|
7 |
+``localrc`` file. See the description of |
|
8 |
+:doc:`local.conf <configuration>` for more details about the mechanics |
|
9 | 9 |
of the file. |
... | ... |
@@ -8,29 +8,30 @@ beginning (which in turn sources the ``localrc`` setion of |
8 | 8 |
``local.conf``) in order to pick up ``HOST_IP`` and/or ``SERVICE_HOST`` |
9 | 9 |
to use in the endpoints. The values shown below are the default values. |
10 | 10 |
|
11 |
-OS\_TENANT\_NAME |
|
12 |
- The introduction of Keystone to the OpenStack ecosystem has |
|
13 |
- standardized the term *tenant* as the entity that owns resources. In |
|
14 |
- some places references still exist to the original Nova term |
|
15 |
- *project* for this use. Also, *tenant\_name* is preferred to |
|
16 |
- *tenant\_id*. |
|
11 |
+OS\_PROJECT\_NAME (OS\_TENANT\_NAME) |
|
12 |
+ Keystone has |
|
13 |
+ standardized the term *project* as the entity that owns resources. In |
|
14 |
+ some places references still exist to the previous term |
|
15 |
+ *tenant* for this use. Also, *project\_name* is preferred to |
|
16 |
+ *project\_id*. OS\_TENANT\_NAME remains supported for compatibility |
|
17 |
+ with older tools. |
|
17 | 18 |
|
18 | 19 |
:: |
19 | 20 |
|
20 |
- OS_TENANT_NAME=demo |
|
21 |
+ OS_PROJECT_NAME=demo |
|
21 | 22 |
|
22 | 23 |
OS\_USERNAME |
23 |
- In addition to the owning entity (tenant), Nova stores the entity |
|
24 |
- performing the action as the *user*. |
|
24 |
+ In addition to the owning entity (project), OpenStack calls the entity |
|
25 |
+ performing the action *user*. |
|
25 | 26 |
|
26 | 27 |
:: |
27 | 28 |
|
28 | 29 |
OS_USERNAME=demo |
29 | 30 |
|
30 | 31 |
OS\_PASSWORD |
31 |
- With Keystone you pass the keystone password instead of an api key. |
|
32 |
- Recent versions of novaclient use OS\_PASSWORD instead of |
|
33 |
- NOVA\_API\_KEYs or NOVA\_PASSWORD. |
|
32 |
+ Keystone's default authentication requires a password be provided. |
|
33 |
+ The usual cautions about putting passwords in environment variables |
|
34 |
+ apply, for most DevStack uses this may be an acceptable tradeoff. |
|
34 | 35 |
|
35 | 36 |
:: |
36 | 37 |
|
... | ... |
@@ -39,7 +40,7 @@ OS\_PASSWORD |
39 | 39 |
HOST\_IP, SERVICE\_HOST |
40 | 40 |
Set API endpoint host using ``HOST_IP``. ``SERVICE_HOST`` may also |
41 | 41 |
be used to specify the endpoint, which is convenient for some |
42 |
- ``localrc`` configurations. Typically, ``HOST_IP`` is set in the |
|
42 |
+ ``local.conf`` configurations. Typically, ``HOST_IP`` is set in the |
|
43 | 43 |
``localrc`` section. |
44 | 44 |
|
45 | 45 |
:: |
... | ... |
@@ -57,15 +58,6 @@ OS\_AUTH\_URL |
57 | 57 |
|
58 | 58 |
OS_AUTH_URL=http://$SERVICE_HOST:5000/v2.0 |
59 | 59 |
|
60 |
-GLANCE\_HOST |
|
61 |
- Some exercises call Glance directly. On a single-node installation, |
|
62 |
- Glance should be listening on ``HOST_IP``. If its running elsewhere |
|
63 |
- it can be set here. |
|
64 |
- |
|
65 |
- :: |
|
66 |
- |
|
67 |
- GLANCE_HOST=$HOST_IP |
|
68 |
- |
|
69 | 60 |
KEYSTONECLIENT\_DEBUG, NOVACLIENT\_DEBUG |
70 | 61 |
Set command-line client log level to ``DEBUG``. These are commented |
71 | 62 |
out by default. |
... | ... |
@@ -73,7 +73,7 @@ Compute (Nova), Network (Nova), Dashboard (Horizon), Orchestration |
73 | 73 |
(Heat) |
74 | 74 |
|
75 | 75 |
Additional services not included directly in DevStack can be tied in to |
76 |
-``stack.sh`` using the `plugin mechanism <plugins.html>`__ to call |
|
76 |
+``stack.sh`` using the :doc:`plugin mechanism <plugins>` to call |
|
77 | 77 |
scripts that perform the configuration and startup of the service. |
78 | 78 |
|
79 | 79 |
Node Configurations |
... | ... |
@@ -8,8 +8,8 @@ support for additional projects and features. |
8 | 8 |
Extras.d Hooks |
9 | 9 |
~~~~~~~~~~~~~~ |
10 | 10 |
|
11 |
-These relatively new hooks are an extension of the existing calls from |
|
12 |
-``stack.sh`` at the end of its run, plus ``unstack.sh`` and |
|
11 |
+These hooks are an extension of the service calls in |
|
12 |
+``stack.sh`` at specific points in its run, plus ``unstack.sh`` and |
|
13 | 13 |
``clean.sh``. A number of the higher-layer projects are implemented in |
14 | 14 |
DevStack using this mechanism. |
15 | 15 |
|
... | ... |
@@ -15,12 +15,12 @@ ENABLED\_SERVICES |
15 | 15 |
Specify which services to launch. These generally correspond to |
16 | 16 |
screen tabs. The default includes: Glance (API and Registry), |
17 | 17 |
Keystone, Nova (API, Certificate, Object Store, Compute, Network, |
18 |
- Scheduler, VNC proxies, Certificate Authentication), Cinder |
|
18 |
+ Scheduler, Certificate Authentication), Cinder |
|
19 | 19 |
(Scheduler, API, Volume), Horizon, MySQL, RabbitMQ, Tempest. |
20 | 20 |
|
21 | 21 |
:: |
22 | 22 |
|
23 |
- ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-net,n-cond,cinder,c-sch,c-api,c-vol,n-sch,n-novnc,n-xvnc,n-cauth,horizon,rabbit,tempest,$DATABASE_TYPE |
|
23 |
+ ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-net,n-cond,c-sch,c-api,c-vol,n-sch,n-cauth,horizon,rabbit,tempest,$DATABASE_TYPE |
|
24 | 24 |
|
25 | 25 |
Other services that are not enabled by default can be enabled in |
26 | 26 |
``localrc``. For example, to add Swift, use the following service |