Prepare for Sphinx 1.5
The new sphinx version introduces some changes that break build: * Warns if code cannot be parsed for highlighting. Fix the code so that it can be parsed, this includes uncommenting "..." lines. Note that not every config file is an ini-file. Also, the parser seems to have bugs and cannot parse all files. Fix mysql ini file and enable the parameter, see http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_file_per_table * :option: works only with declared options, replace useage with simple ``. This change only handles a few files, more to come later. Change-Id: I7c7335e514581622dd562ee355f62d6ae1beaa18
This commit is contained in:
Andreas Jaeger
parent
3a438be06e
commit
2d44b2b36d
@ -59,14 +59,14 @@ You can apply this process to volumes of any size.
|
||||
# lvcreate --size 10G --snapshot --name volume-00000001-snapshot \
|
||||
/dev/cinder-volumes/volume-00000001
|
||||
|
||||
Use the :option:`--snapshot` configuration option to tell LVM that you want a
|
||||
Use the ``--snapshot`` configuration option to tell LVM that you want a
|
||||
snapshot of an already existing volume. The command includes the size
|
||||
of the space reserved for the snapshot volume, the name of the snapshot,
|
||||
and the path of an already existing volume. Generally, this path
|
||||
is ``/dev/cinder-volumes/VOLUME_NAME``.
|
||||
|
||||
The size does not have to be the same as the volume of the snapshot.
|
||||
The :option:`--size` parameter defines the space that LVM reserves
|
||||
The ``--size`` parameter defines the space that LVM reserves
|
||||
for the snapshot volume. As a precaution, the size should be the same
|
||||
as that of the original volume, even if the whole space is not
|
||||
currently used by the snapshot.
|
||||
|
||||
@ -12,7 +12,7 @@ group operations can be performed using the Block Storage command line.
|
||||
.. note::
|
||||
|
||||
Only Block Storage V2 API supports consistency groups. You can
|
||||
specify :option:`--os-volume-api-version 2` when using Block Storage
|
||||
specify ``--os-volume-api-version 2`` when using Block Storage
|
||||
command line for consistency group operations.
|
||||
|
||||
Before using consistency groups, make sure the Block Storage driver that
|
||||
|
||||
@ -39,7 +39,7 @@ found in `Cinder specs <https://github.com/openstack/cinder-specs/blob/master/sp
|
||||
.. note::
|
||||
|
||||
Only Block Storage V3 API supports groups. You can
|
||||
specify :option:`--os-volume-api-version 3.x` when using the `cinder`
|
||||
specify ``--os-volume-api-version 3.x`` when using the `cinder`
|
||||
command line for group operations where `3.x` contains a microversion value
|
||||
for that command. The generic volume group feature was completed in several
|
||||
patches. As a result, the minimum required microversion is different for
|
||||
@ -137,7 +137,7 @@ microversion to support group type and group specs is 3.11:
|
||||
.. note::
|
||||
|
||||
The parameter ``NAME`` is required. The
|
||||
:option:`--is-public IS_PUBLIC` determines whether the group type is
|
||||
``--is-public IS_PUBLIC`` determines whether the group type is
|
||||
accessible to the public. It is ``True`` by default. By default, the
|
||||
policy on privileges for creating a group type is admin-only.
|
||||
|
||||
@ -256,7 +256,7 @@ microversion to support groups operations is 3.13.
|
||||
|
||||
.. note::
|
||||
|
||||
:option:`--all-tenants` specifies whether to list groups for all tenants.
|
||||
``--all-tenants`` specifies whether to list groups for all tenants.
|
||||
Only admin can use this option.
|
||||
|
||||
**Create a volume and add it to a group**:
|
||||
@ -283,9 +283,9 @@ microversion to support groups operations is 3.13.
|
||||
|
||||
.. note::
|
||||
|
||||
:option:`--delete-volumes` allows or disallows groups to be deleted
|
||||
``--delete-volumes`` allows or disallows groups to be deleted
|
||||
if they are not empty. If the group is empty, it can be deleted without
|
||||
:option:`--delete-volumes`. If the group is not empty, the flag is
|
||||
``--delete-volumes``. If the group is not empty, the flag is
|
||||
required for it to be deleted. When the flag is specified, the group
|
||||
and all volumes in the group will be deleted.
|
||||
|
||||
@ -345,9 +345,9 @@ minimum microversion to support group snapshots operations is 3.14.
|
||||
|
||||
.. note::
|
||||
|
||||
:option:`--all-tenants` specifies whether to list group snapshots for
|
||||
all tenants. Only admin can use this option. :option:`--status STATUS`
|
||||
filters results by a status. :option:`--group-id GROUP_ID` filters
|
||||
``--all-tenants`` specifies whether to list group snapshots for
|
||||
all tenants. Only admin can use this option. ``--status STATUS``
|
||||
filters results by a status. ``--group-id GROUP_ID`` filters
|
||||
results by a group id.
|
||||
|
||||
**Delete group snapshot**:
|
||||
|
||||
@ -84,9 +84,9 @@ laying on top of it in order.
|
||||
|
||||
You can view a backup list with the :command:`cinder backup-list`
|
||||
command. Optional arguments to clarify the status of your backups
|
||||
include: running :option:`--name`, :option:`--status`, and
|
||||
:option:`--volume-id` to filter through backups by the specified name,
|
||||
status, or volume-id. Search with :option:`--all-tenants` for details of the
|
||||
include: running ``--name``, ``--status``, and
|
||||
``--volume-id`` to filter through backups by the specified name,
|
||||
status, or volume-id. Search with ``--all-tenants`` for details of the
|
||||
projects associated with the listed backups.
|
||||
|
||||
Because volume backups are dependent on the Block Storage database, you must
|
||||
|
||||
@ -6,10 +6,10 @@ Use the swift command-line client for Object Storage to analyze log files.
|
||||
|
||||
The swift client is simple to use, scalable, and flexible.
|
||||
|
||||
Use the swift client :option:`-o` or :option:`-output` option to get
|
||||
Use the swift client ``-o`` or ``-output`` option to get
|
||||
short answers to questions about logs.
|
||||
|
||||
You can use the :option:`-o` or :option:`--output` option with a single object
|
||||
You can use the ``-o`` or ``--output`` option with a single object
|
||||
download to redirect the command output to a specific file or to STDOUT
|
||||
(``-``). The ability to redirect the output to STDOUT enables you to
|
||||
pipe (``|``) data without saving it to disk first.
|
||||
@ -102,7 +102,7 @@ Upload and analyze log files
|
||||
Download and analyze an object
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This example uses the :option:`-o` option and a hyphen (``-``) to get
|
||||
This example uses the ``-o`` option and a hyphen (``-``) to get
|
||||
information about an object.
|
||||
|
||||
Use the :command:`swift download` command to download the object. On this
|
||||
@ -159,8 +159,8 @@ return code combination.
|
||||
|
||||
#. Discover how many PUT requests are in each log file.
|
||||
|
||||
Use a bash for loop with awk and swift with the :option:`-o` or
|
||||
:option:`--output` option and a hyphen (``-``) to discover how many
|
||||
Use a bash for loop with awk and swift with the ``-o`` or
|
||||
``--output`` option and a hyphen (``-``) to discover how many
|
||||
PUT requests are in each log file.
|
||||
|
||||
Run the :command:`swift list` command to list objects in the logtest
|
||||
|
||||
@ -30,7 +30,7 @@ following example:
|
||||
|
||||
$ manila migrate shareID destinationHost --force-host-copy True|False
|
||||
|
||||
In this example, :option:`--force-host-copy True` forces the generic
|
||||
In this example, ``--force-host-copy True`` forces the generic
|
||||
host-based migration mechanism and bypasses any driver optimizations.
|
||||
``destinationHost`` is in this format ``host#pool`` which includes
|
||||
destination host and pool.
|
||||
|
||||
@ -180,14 +180,14 @@ the default set of quotas are enforced for all projects, so no
|
||||
The :command:`neutron quota-show` command reports the current
|
||||
set of quota limits for the specified project.
|
||||
Non-administrative users can run this command without the
|
||||
:option:`--tenant_id` parameter. If per-project quota limits are
|
||||
``--tenant_id`` parameter. If per-project quota limits are
|
||||
not enabled for the project, the command shows the default
|
||||
set of quotas.
|
||||
|
||||
.. note::
|
||||
|
||||
Additional quotas added in the Mitaka release include :option:`security_group`,
|
||||
:option:`security_group_rule`, :option:`subnet`, and :option:`subnetpool`.
|
||||
Additional quotas added in the Mitaka release include ``security_group``,
|
||||
``security_group_rule``, ``subnet``, and ``subnetpool``.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ current VM host is not operational. Otherwise, the evacuation fails.
|
||||
|
||||
$ openstack host list
|
||||
|
||||
#. Evacuate the instance. You can use the :option:`--password PWD` option
|
||||
#. Evacuate the instance. You can use the ``--password PWD`` option
|
||||
to pass the instance password to the command. If you do not specify a
|
||||
password, the command generates and prints one after it finishes
|
||||
successfully. The following command evacuates a server from a failed host
|
||||
|
||||
@ -7,7 +7,7 @@ host instances are launched on and which roles can boot instances
|
||||
on this host.
|
||||
|
||||
#. To select the host where instances are launched, use
|
||||
the :option:`--availability-zone ZONE:HOST:NODE` parameter on the
|
||||
the ``--availability-zone ZONE:HOST:NODE`` parameter on the
|
||||
:command:`openstack server create` command.
|
||||
|
||||
For example:
|
||||
@ -21,7 +21,7 @@ on this host.
|
||||
|
||||
.. note::
|
||||
HOST is an optional parameter. In such cases,
|
||||
use the :option:`--availability-zone ZONE::NODE`.
|
||||
use the ``--availability-zone ZONE::NODE``.
|
||||
|
||||
|
||||
#. To specify which roles can launch an instance on a
|
||||
|
||||
@ -119,7 +119,7 @@ resources.
|
||||
|
||||
Earlier versions of OpenStack used the term ``tenant`` instead of
|
||||
``project``. Because of this legacy terminology, some command-line tools
|
||||
use :option:`--tenant_id` where you would normally expect to enter a
|
||||
use ``--tenant_id`` where you would normally expect to enter a
|
||||
project ID.
|
||||
|
||||
Block storage
|
||||
|
||||
@ -305,7 +305,7 @@ configuration is required.
|
||||
|
||||
.. note::
|
||||
|
||||
- To use block migration, you must use the :option:`--block-migrate`
|
||||
- To use block migration, you must use the ``--block-migrate``
|
||||
parameter with the live migration command.
|
||||
|
||||
- Block migration is incompatible with read-only devices such as
|
||||
@ -409,7 +409,7 @@ Block migration
|
||||
|
||||
.. note::
|
||||
|
||||
- To use block migration, you must use the :option:`--block-migrate`
|
||||
- To use block migration, you must use the ``--block-migrate``
|
||||
parameter with the live migration command.
|
||||
|
||||
- Block migration works only with EXT local storage storage
|
||||
|
||||
@ -51,7 +51,7 @@ specific commands might be restricted by the Identity service.
|
||||
<http://docs.openstack.org/cli-reference/openstack.html>`__.
|
||||
|
||||
#. Set the required parameters as environment variables to make running
|
||||
commands easier. For example, you can add :option:`--os-username` as an
|
||||
commands easier. For example, you can add ``--os-username`` as an
|
||||
``openstack`` option, or set it as an environment variable. To set the user
|
||||
name, password, and project as environment variables, use:
|
||||
|
||||
|
||||
@ -390,7 +390,7 @@ retrieve the metadata, make a GET request to
|
||||
}
|
||||
|
||||
Instances also retrieve user data (passed as the ``user_data`` parameter
|
||||
in the API call or by the :option:`--user_data` flag in the
|
||||
in the API call or by the ``--user_data`` flag in the
|
||||
:command:`openstack server create` command) through the metadata service, by making a
|
||||
GET request to ``http://169.254.169.254/openstack/2012-08-10/user_data``:
|
||||
|
||||
@ -834,7 +834,7 @@ Edit the ``/etc/network/interfaces`` file:
|
||||
iface eth1 inet dhcp
|
||||
|
||||
If the Virtual Network Service Neutron is installed, you can specify the
|
||||
networks to attach to the interfaces by using the :option:`--nic` flag with
|
||||
networks to attach to the interfaces by using the ``--nic`` flag with
|
||||
the :command:`openstack server create` command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -38,7 +38,7 @@ To manually recover a failed compute node:
|
||||
:command:`nova` commands, you can substitute the ID directly. This example
|
||||
output is truncated:
|
||||
|
||||
.. code-block:: mysql
|
||||
.. code-block:: none
|
||||
|
||||
mysql> SELECT * FROM instances WHERE id = CONV('15b9', 16, 10) \G;
|
||||
*************************** 1. row ***************************
|
||||
@ -327,7 +327,7 @@ iSCSI session. This example closes an iSCSI session with the number ``15``:
|
||||
|
||||
# iscsiadm -m session -u -r 15
|
||||
|
||||
Do not forget the :option:`-r` option. Otherwise, all sessions close.
|
||||
Do not forget the ``-r`` option. Otherwise, all sessions close.
|
||||
|
||||
.. warning::
|
||||
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
|
||||
=====================================
|
||||
Customize and configure the Dashboard
|
||||
=====================================
|
||||
@ -357,7 +356,7 @@ Use a domain that fits your current setup.
|
||||
|
||||
**Example After**
|
||||
|
||||
.. code-block:: apacheconf
|
||||
.. code-block:: none
|
||||
|
||||
<VirtualHost *:80>
|
||||
ServerName openstack.example.com
|
||||
@ -436,7 +435,7 @@ Use a domain that fits your current setup.
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
ssl_only = true
|
||||
cert = /etc/apache2/SSL/openstack.example.com.crt
|
||||
key = /etc/apache2/SSL/openstack.example.com.key
|
||||
@ -447,5 +446,5 @@ Use a domain that fits your current setup.
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
novncproxy_base_url = https://controller:6080/vnc_auto.html
|
||||
|
||||
@ -121,7 +121,7 @@ data store version.
|
||||
- In this example:
|
||||
* - config file
|
||||
- The configuration file to use.
|
||||
- :option:`--config-file=/etc/trove/trove.conf`
|
||||
- ``--config-file=/etc/trove/trove.conf``
|
||||
* - name
|
||||
- Name you want to use for this data store.
|
||||
- ``mysql``
|
||||
@ -162,7 +162,7 @@ data store version.
|
||||
|
||||
* - config file
|
||||
- The configuration file to use.
|
||||
- :option:`--config-file=/etc/trove/trove.conf`
|
||||
- ``--config-file=/etc/trove/trove.conf``
|
||||
|
||||
* - data store
|
||||
- The name of the data store you just created via
|
||||
|
||||
@ -26,7 +26,7 @@ And set the following values in ``nova.conf`` as follows:
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
auth_strategy=keystone
|
||||
|
||||
[keystone_authtoken]
|
||||
|
||||
@ -22,7 +22,7 @@ the system user that will run the Identity service.
|
||||
going to sign tokens. When generating files with the
|
||||
:command:`keystone-manage pki_setup` command, your best option is to run
|
||||
as the pki user. If you run :command:`keystone-manage` as root, you can
|
||||
append :option:`--keystone-user` and :option:`--keystone-group` parameters
|
||||
append ``--keystone-user`` and ``--keystone-group`` parameters
|
||||
to set the user name and group keystone is going to run under.
|
||||
|
||||
The values that specify where to read the certificates are under the
|
||||
|
||||
@ -160,7 +160,7 @@ is required for Compute operations.
|
||||
For example, the following line in the ``/etc/cinder/policy.json``
|
||||
file does not restrict which users can create volumes:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"volume:create": "",
|
||||
|
||||
@ -170,7 +170,7 @@ project.
|
||||
To restrict the creation of volumes to users who have the
|
||||
``compute-user`` role in a particular project, you add ``"role:compute-user"``:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"volume:create": "role:compute-user",
|
||||
|
||||
|
||||
@ -24,7 +24,7 @@ Use X.509
|
||||
The following Apache configuration snippet authenticates the user based
|
||||
on a valid X.509 certificate from a known CA:
|
||||
|
||||
.. code-block:: apacheconf
|
||||
.. code-block:: none
|
||||
|
||||
<VirtualHost _default_:5000>
|
||||
SSLEngine on
|
||||
|
||||
@ -12,7 +12,7 @@ certain actions in defined services.
|
||||
Each Identity API v3 call has a line in the policy file that dictates
|
||||
which level of governance of access applies.
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
API_NAME: RULE_STATEMENT or MATCH_STATEMENT
|
||||
|
||||
@ -25,7 +25,7 @@ Where:
|
||||
token provided by the caller of the API and the parameters or target
|
||||
entities of the API call in question. For example:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
"identity:create_user": "role:admin and domain_id:%(user.domain_id)s"
|
||||
|
||||
@ -39,7 +39,7 @@ must be scoped to that domain.
|
||||
|
||||
Each component of a match statement uses this format:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
ATTRIB_FROM_TOKEN:CONSTANT or ATTRIB_RELATED_TO_API_CALL
|
||||
|
||||
@ -64,7 +64,7 @@ You reference attributes of objects passed with an object.attribute
|
||||
syntax (such as, ``user.domain_id``). The target objects of an API are
|
||||
also available using a target.object.attribute syntax. For instance:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
"identity:delete_user": "role:admin and domain_id:%(target.user.domain_id)s"
|
||||
|
||||
@ -79,7 +79,7 @@ such as user passwords.
|
||||
|
||||
List of object attributes:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: yaml
|
||||
|
||||
role:
|
||||
target.role.id
|
||||
|
||||
@ -19,7 +19,7 @@ location of log files.
|
||||
The logs show the components that have come in to the WSGI request, and
|
||||
ideally show an error that explains why an authorization request failed.
|
||||
If you do not see the request in the logs, run keystone with the
|
||||
:option:`--debug` parameter. Pass the :option:`--debug` parameter before the
|
||||
``--debug`` parameter. Pass the ``--debug`` parameter before the
|
||||
command parameters.
|
||||
|
||||
Debug PKI middleware
|
||||
@ -165,8 +165,8 @@ is owned by ``root:root``. This can present a problem when you run the
|
||||
Identity daemon under the keystone user account (nologin) when you try
|
||||
to run PKI. Unless you run the :command:`chown` command against the
|
||||
files ``keystone:keystone``, or run the :command:`keystone-manage pki_setup`
|
||||
command with the :option:`--keystone-user` and
|
||||
:option:`--keystone-group` parameters, you will get an error.
|
||||
command with the ``--keystone-user`` and
|
||||
``--keystone-group`` parameters, you will get an error.
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -44,8 +44,7 @@ Currently the only available implementation uses iptables for metering.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
driver = neutron.services.metering.drivers.
|
||||
iptables.iptables_driver.IptablesMeteringDriver
|
||||
driver = neutron.services.metering.drivers.iptables.iptables_driver.IptablesMeteringDriver
|
||||
|
||||
L3 metering service driver
|
||||
--------------------------
|
||||
|
||||
@ -426,11 +426,11 @@ basic LBaaS operations:
|
||||
|
||||
- Creates a load balancer pool by using specific provider.
|
||||
|
||||
:option:`--provider` is an optional argument. If not used, the pool is
|
||||
``--provider`` is an optional argument. If not used, the pool is
|
||||
created with default provider for LBaaS service. You should configure
|
||||
the default provider in the ``[service_providers]`` section of the
|
||||
``neutron.conf`` file. If no default provider is specified for LBaaS,
|
||||
the :option:`--provider` parameter is required for pool creation.
|
||||
the ``--provider`` parameter is required for pool creation.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
||||
@ -90,7 +90,7 @@ This extract is from the default ``policy.json`` file:
|
||||
administrator or the owner of the resource specified in the request
|
||||
(project identifier is equal).
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
{
|
||||
"admin_or_owner": [
|
||||
@ -126,7 +126,7 @@ This extract is from the default ``policy.json`` file:
|
||||
- The default policy that is always evaluated if an API operation does
|
||||
not match any of the policies in ``policy.json``.
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"rule:admin_or_owner"
|
||||
]
|
||||
@ -163,7 +163,7 @@ This extract is from the default ``policy.json`` file:
|
||||
- This policy evaluates successfully if either *admin\_or\_owner*, or
|
||||
*shared* evaluates successfully.
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
[
|
||||
"rule:shared"
|
||||
@ -177,7 +177,7 @@ This extract is from the default ``policy.json`` file:
|
||||
- This policy restricts the ability to manipulate the *shared*
|
||||
attribute for a network to administrators only.
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
],
|
||||
"update_network": [
|
||||
@ -202,7 +202,7 @@ This extract is from the default ``policy.json`` file:
|
||||
attribute for a port only to administrators and the owner of the
|
||||
network where the port is attached.
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
[
|
||||
"rule:admin_or_network_owner"
|
||||
@ -230,7 +230,7 @@ This example shows you how to modify a policy file to permit project to
|
||||
define networks, see their resources, and permit administrative users to
|
||||
perform all other operations:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
{
|
||||
"admin_or_owner": [["role:admin"], ["tenant_id:%(tenant_id)s"]],
|
||||
|
||||
@ -225,7 +225,7 @@ capabilities:
|
||||
communication is interrupted. To avoid this, edit the
|
||||
``/etc/network/interfaces`` file to contain the following information:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: shell
|
||||
|
||||
## External bridge
|
||||
auto br-ex
|
||||
@ -332,8 +332,7 @@ The Neutron Metering agent resides beside neutron-l3-agent.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
driver = neutron.services.metering.drivers.iptables.iptables_driver
|
||||
.IptablesMeteringDriver
|
||||
driver = neutron.services.metering.drivers.iptables.iptables_driver.IptablesMeteringDriver
|
||||
|
||||
#. Set the ``service_plugins`` option in the ``/etc/neutron/neutron.conf``
|
||||
file on the host that runs ``neutron-server``:
|
||||
@ -365,8 +364,7 @@ This example uses Octavia.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.
|
||||
drivers.octavia.driver.OctaviaDriver:default
|
||||
service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
|
||||
|
||||
|
||||
#. Edit the ``/etc/neutron/neutron.conf`` file and add the
|
||||
@ -467,8 +465,7 @@ correctly using these
|
||||
enable_metrics_collection = true
|
||||
|
||||
[SECURITYGROUP]
|
||||
firewall_driver = hyperv.neutron.security_groups_driver.
|
||||
HyperVSecurityGroupsDriver
|
||||
firewall_driver = hyperv.neutron.security_groups_driver.HyperVSecurityGroupsDriver
|
||||
enable_security_group = true
|
||||
|
||||
#. Start the OpenStack Networking Hyper-V agent:
|
||||
@ -496,7 +493,7 @@ complete basic operations on agents.
|
||||
- ``$ openstack network agent show AGENT_ID``
|
||||
* - Update the admin status and description for a specified agent. The
|
||||
command can be used to enable and disable agents by using
|
||||
:option:`--admin-state-up` parameter set to ``False`` or ``True``.
|
||||
``--admin-state-up`` parameter set to ``False`` or ``True``.
|
||||
- ``$ neutron agent-update --admin-state-up False AGENT_ID``
|
||||
* - Delete a given agent. Consider disabling the agent before deletion.
|
||||
- ``$ openstack network agent delete AGENT_ID``
|
||||
|
||||
@ -11,7 +11,7 @@ Configure Identity service for Networking
|
||||
|
||||
a. Add the following function to your ``.bashrc`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: bash
|
||||
|
||||
function get_id () {
|
||||
echo `"$@" | awk '/ id / { print $4 }'`
|
||||
|
||||
@ -141,7 +141,7 @@ require accuracy (``sample_rate=1``) while others may not.
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
log_statsd_host = 127.0.0.1
|
||||
log_statsd_port = 8125
|
||||
log_statsd_default_sample_rate = 1
|
||||
|
||||
@ -87,7 +87,7 @@ Check that consistency group status is ``available``:
|
||||
+----------------------+--------------------------------------+
|
||||
|
||||
To add a share to the consistency group, create a share by adding the
|
||||
:option:`--consistency-group` option where you specify the ID of the consistency
|
||||
``--consistency-group`` option where you specify the ID of the consistency
|
||||
group in ``available`` status:
|
||||
|
||||
.. code-block:: console
|
||||
@ -207,7 +207,7 @@ description using the :command:`cg-snapshot-update` command, or delete
|
||||
it with the :command:`cg-snapshot-delete` command.
|
||||
|
||||
A consistency group snapshot can have ``members``. To add a member,
|
||||
include the :option:`--consistency-group` optional parameter in the
|
||||
include the ``--consistency-group`` optional parameter in the
|
||||
create share command. This ID must match the ID of the consistency group from
|
||||
which the consistency group snapshot was created. Then, while restoring data,
|
||||
and operating with consistency group snapshots, you can quickly
|
||||
@ -318,5 +318,5 @@ Print detailed information about new share:
|
||||
As an administrator, you can also reset the state of a consistency group
|
||||
snapshot with the :command:`cg-snapshot-reset-state` command, and force delete a specified
|
||||
consistency group snapshot in any state using the :command:`cg-snapshot-delete` command
|
||||
with the :option:`--force` key. Use the ``policy.json`` file to grant permissions for
|
||||
with the ``--force`` key. Use the ``policy.json`` file to grant permissions for
|
||||
these actions to other roles.
|
||||
|
||||
@ -582,7 +582,7 @@ Use **manila delete <share_name_or_ID>** command to delete a specified share:
|
||||
.. note::
|
||||
|
||||
If you specified :ref:`the consistency group <shared_file_systems_cgroups>`
|
||||
while creating a share, you should provide the :option:`--consistency-group`
|
||||
while creating a share, you should provide the ``--consistency-group``
|
||||
parameter to delete the share:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -25,7 +25,7 @@ following example:
|
||||
|
||||
$ manila migrate shareID destinationHost --force-host-copy True|False
|
||||
|
||||
In this example, :option:`--force-host-copy True` forces the generic
|
||||
In this example, ``--force-host-copy True`` forces the generic
|
||||
host-based migration mechanism and bypasses any driver optimizations.
|
||||
``destinationHost`` is in this format ``host#pool`` which includes
|
||||
destination host and pool.
|
||||
|
||||
@ -86,7 +86,7 @@ Quotas
|
||||
Quota sets provide quota management support.
|
||||
|
||||
To list the quotas for a project or user, use the :command:`manila quota-show`
|
||||
command. If you specify the optional :option:`--user` parameter, you get the
|
||||
command. If you specify the optional ``--user`` parameter, you get the
|
||||
quotas for this user in the specified project. If you omit this parameter,
|
||||
you get the quotas for the specified project.
|
||||
|
||||
|
||||
@ -174,9 +174,9 @@ share networks:
|
||||
|
||||
The Shared File Systems service allows you to update a security service field
|
||||
using :command:`manila security-service-update` command with optional
|
||||
arguments such as :option:`--dns-ip`, :option:`--server`, :option:`--domain`,
|
||||
:option:`--user`, :option:`--password`, :option:`--name`, or
|
||||
:option:`--description`.
|
||||
arguments such as ``--dns-ip``, ``--server``, ``--domain``,
|
||||
``--user``, ``--password``, ``--name``, or
|
||||
``--description``.
|
||||
|
||||
To remove a security service not associated with any share networks
|
||||
run:
|
||||
|
||||
@ -71,7 +71,7 @@ share type creation with extra specifications to other roles.
|
||||
You set a share type to private or public and
|
||||
:ref:`manage the access<share_type_access>` to the private share types. By
|
||||
default a share type is created as publicly accessible. Set
|
||||
:option:`--is_public` to ``False`` to make the share type private.
|
||||
``--is_public`` to ``False`` to make the share type private.
|
||||
|
||||
Share type operations
|
||||
---------------------
|
||||
@ -149,7 +149,7 @@ Create a private type:
|
||||
|
||||
If you run :command:`manila type-list` only public share types appear.
|
||||
To see private share types, run :command:`manila type-list` with
|
||||
:option:`--all` optional argument.
|
||||
``--all`` optional argument.
|
||||
|
||||
Grant access to created private type for a demo and alt_demo projects
|
||||
by providing their IDs:
|
||||
|
||||
@ -63,7 +63,7 @@ Check that status of a snapshot is ``available``:
|
||||
+-------------+--------------------------------------+
|
||||
|
||||
To restore your data from a snapshot, use :command:`manila create` with
|
||||
key :option:`--snapshot-id`. This creates a new share from an
|
||||
key ``--snapshot-id``. This creates a new share from an
|
||||
existing snapshot. Create a share from a snapshot and check whether
|
||||
it is available:
|
||||
|
||||
|
||||
@ -221,7 +221,7 @@ instance. For example:
|
||||
$ nova reset-state c6bbbf26-b40a-47e7-8d5c-eb17bf65c485
|
||||
$ openstack server delete c6bbbf26-b40a-47e7-8d5c-eb17bf65c485
|
||||
|
||||
You can also use the :option:`--active` parameter to force the instance back
|
||||
You can also use the ``--active`` parameter to force the instance back
|
||||
to an active state instead of an error state. For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -508,11 +508,11 @@ If the sample corresponds to an existing meter, then the fields like
|
||||
The required fields for sending a sample using the command-line client
|
||||
are:
|
||||
|
||||
- ID of the corresponding resource. (:option:`--resource-id`)
|
||||
- ID of the corresponding resource. (``--resource-id``)
|
||||
|
||||
- Name of meter. (:option:`--meter-name`)
|
||||
- Name of meter. (``--meter-name``)
|
||||
|
||||
- Type of meter. (:option:`--meter-type`)
|
||||
- Type of meter. (``--meter-type``)
|
||||
|
||||
Predefined meter types:
|
||||
|
||||
@ -522,9 +522,9 @@ are:
|
||||
|
||||
- Cumulative
|
||||
|
||||
- Unit of meter. (:option:`--meter-unit`)
|
||||
- Unit of meter. (``--meter-unit``)
|
||||
|
||||
- Volume of sample. (:option:`--sample-volume`)
|
||||
- Volume of sample. (``--sample-volume``)
|
||||
|
||||
To send samples to Telemetry using the command-line client, the
|
||||
following command should be invoked:
|
||||
|
||||
@ -323,7 +323,7 @@ Multi meter arithmetic transformer
|
||||
This transformer enables us to perform arithmetic calculations over one
|
||||
or more meters and/or their metadata, for example:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
memory_util = 100 * memory.usage / memory
|
||||
|
||||
|
||||
@ -201,7 +201,7 @@ in the Installation Tutorials and Guides.
|
||||
|
||||
Similarly to other OpenStack command-line clients, the ``ceilometer``
|
||||
client uses OpenStack Identity for authentication. The proper
|
||||
credentials and :option:`--auth_url` parameter have to be defined via command
|
||||
credentials and ``--auth_url`` parameter have to be defined via command
|
||||
line parameters or environment variables.
|
||||
|
||||
This section provides some examples without the aim of completeness.
|
||||
@ -350,7 +350,7 @@ complex operators, it is possible to retrieve a subset of samples for a
|
||||
given VM instance. To request for the first six samples for the ``cpu``
|
||||
and ``disk.read.bytes`` meters, the following command should be invoked:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: none
|
||||
|
||||
$ ceilometer query-samples --filter '{"and": \
|
||||
[{"=":{"resource":"bb52e52b-1e42-4751-b3ac-45c52d83ba07"}},{"or":[{"=":{"counter_name":"cpu"}}, \
|
||||
@ -414,8 +414,7 @@ retrieve specific events:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ceilometer event-list -q 'event_type=compute.instance.exists; \
|
||||
instance_type=m1.tiny'
|
||||
$ ceilometer event-list -q 'event_type=compute.instance.exists;instance_type=m1.tiny'
|
||||
+--------------------------------------+-------------------------+----------------------------+----------------------------------------------------------------------------------+
|
||||
| Message ID | Event Type | Generated | Traits |
|
||||
+--------------------------------------+-------------------------+----------------------------+----------------------------------------------------------------------------------+
|
||||
|
||||
@ -194,7 +194,7 @@ To fix this issue, change the content of the ``/etc/tgt/targets.conf``
|
||||
file from ``include /etc/tgt/conf.d/*.conf`` to
|
||||
``include /etc/tgt/conf.d/cinder_tgt.conf``, as follows:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: shell
|
||||
|
||||
include /etc/tgt/conf.d/cinder_tgt.conf
|
||||
include /etc/tgt/conf.d/cinder.conf
|
||||
|
||||
@ -238,7 +238,7 @@ that can be installed without ``pip``.
|
||||
Upgrade or remove clients
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To upgrade a client, add the :option:`--upgrade` option to the
|
||||
To upgrade a client, add the ``--upgrade`` option to the
|
||||
:command:`pip install` command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -33,9 +33,9 @@ following example:
|
||||
--lock-volume <True|False>
|
||||
<volume> <host>
|
||||
|
||||
In this example, :option:`--force-host-copy True` forces the generic
|
||||
In this example, ``--force-host-copy True`` forces the generic
|
||||
host-based migration mechanism and bypasses any driver optimizations.
|
||||
:option:`--lock-volume <True|False>` applies to the available volume.
|
||||
``--lock-volume <True|False>`` applies to the available volume.
|
||||
To determine whether the termination of volume migration caused by other
|
||||
commands. ``True`` locks the volume state and does not allow the
|
||||
migration to be aborted.
|
||||
@ -621,17 +621,17 @@ Manage a snapshot with the :command:`openstack snapshot set` command:
|
||||
|
||||
The arguments to be passed are:
|
||||
|
||||
:option:`--name <name>`
|
||||
``--name <name>``
|
||||
New snapshot name
|
||||
|
||||
:option:`--description <description>`
|
||||
``--description <description>``
|
||||
New snapshot description
|
||||
|
||||
:option:`--property <key=value>`
|
||||
``--property <key=value>``
|
||||
Property to add or modify for this snapshot (repeat option to set
|
||||
multiple properties)
|
||||
|
||||
:option:`--state <state>`
|
||||
``--state <state>``
|
||||
New snapshot state. (“available”, “error”, “creating”, “deleting”,
|
||||
or “error_deleting”)
|
||||
(admin only) (This option simply changes the state of the snapshot in the
|
||||
|
||||
@ -98,7 +98,7 @@ scratch, if you cannot download the file from the dashboard.
|
||||
lives in clear text format in the ``PROJECT-openrc.sh`` file.
|
||||
Restrict the permissions on this file to avoid security problems.
|
||||
You can also remove the ``OS_PASSWORD`` variable from the file, and
|
||||
use the :option:`--password` parameter with OpenStack client commands
|
||||
use the ``--password`` parameter with OpenStack client commands
|
||||
instead.
|
||||
|
||||
.. note::
|
||||
@ -132,7 +132,7 @@ or command-line argument. It is not safe to specify the password using
|
||||
either of these methods.
|
||||
|
||||
For example, when you specify your password using the command-line
|
||||
client with the :option:`--os-password` argument, anyone with access to your
|
||||
client with the ``--os-password`` argument, anyone with access to your
|
||||
computer can view it in plain text with the ``ps`` field.
|
||||
|
||||
To avoid storing the password in plain text, you can prompt for the
|
||||
|
||||
@ -150,7 +150,7 @@ CoprHD drivers - Single back end
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
rpc_response_timeout = 300
|
||||
|
||||
#. Now, restart the ``cinder-volume`` service.
|
||||
|
||||
@ -136,7 +136,7 @@ The following configuration is for 3.X Linux kernels, some parameters in
|
||||
different Linux distributions may be different. Make the following changes
|
||||
in the ``multipath.conf`` file:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
defaults {
|
||||
checker_timer 5
|
||||
|
||||
@ -139,10 +139,10 @@ Configuring the array
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
enabled_backends = pool-a,pool-b
|
||||
default_volume_type = dothill
|
||||
...
|
||||
# ...
|
||||
|
||||
#. Create a new volume type for each distinct ``volume_backend_name`` value
|
||||
that you added to cinder.conf. The example below assumes that the same
|
||||
|
||||
@ -381,7 +381,7 @@ attached over iSCSI or ``F`` for volumes attached over Fiber Channel.
|
||||
|
||||
VMAX All Flash and Hybrid
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
OS-[shortHostName]-[SRP]-[SLO]-[workload]-[protocol]-MV
|
||||
|
||||
@ -397,7 +397,7 @@ as required. Names are of the following format. ``[protocol]`` is either ``I``
|
||||
for volumes attached over iSCSI or ``F`` for volumes attached over Fiber
|
||||
Channel.
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
OS-[shortHostName]-[protocol]-IG
|
||||
|
||||
@ -424,7 +424,7 @@ or ``F`` for volumes attached over Fiber Channel.
|
||||
|
||||
VMAX All Flash and Hybrid
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
OS-[shortHostName]-[SRP]-[SLO]-[Workload]-[protocol]-SG
|
||||
|
||||
@ -811,7 +811,7 @@ The multipath configuration file may be edited for better management and
|
||||
performance. Log in as a privileged user and make the following changes to
|
||||
:file:`/etc/multipath.conf` on the Compute (nova) node(s).
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
devices {
|
||||
# Device attributed for EMC VMAX
|
||||
@ -842,7 +842,7 @@ On Ubuntu:
|
||||
# service open-iscsi restart
|
||||
# service multipath-tools restart
|
||||
|
||||
On On openSUSE, SUSE Linux Enterprise Server, Red Hat Enterprise Linux, and
|
||||
On openSUSE, SUSE Linux Enterprise Server, Red Hat Enterprise Linux, and
|
||||
CentOS:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -946,8 +946,8 @@ configuration file. Following is the instruction on how to do this.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# su -l cinder -c '/opt/Navisphere/bin/naviseccli \
|
||||
-AddUserSecurity -user admin -password admin -scope 0 -secfilepath <location>'
|
||||
# su -l cinder -c \
|
||||
'/opt/Navisphere/bin/naviseccli -AddUserSecurity -user admin -password admin -scope 0 -secfilepath <location>'
|
||||
|
||||
#. Change ``cinder:x:113:120::/var/lib/cinder:/bin/bash`` back to
|
||||
``cinder:x:113:120::/var/lib/cinder:/bin/false`` in ``/etc/passwd`` file.
|
||||
|
||||
@ -298,7 +298,7 @@ For example:
|
||||
.. code-block:: ini
|
||||
|
||||
[hnas-backend]
|
||||
…
|
||||
# ...
|
||||
hnas_username = supervisor
|
||||
hnas_password = supervisor
|
||||
|
||||
@ -363,7 +363,7 @@ through public key. To configure that:
|
||||
.. code-block:: ini
|
||||
|
||||
[hnas-backend]
|
||||
…
|
||||
# ...
|
||||
hnas_ssh_private_key = /opt/hitachi/ssh/hnaskey
|
||||
|
||||
Managing volumes
|
||||
@ -530,7 +530,7 @@ Below are configuration examples for both NFS and iSCSI backends:
|
||||
|
||||
#. Add the configured exports to the ``nfs_shares`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
172.24.49.21:/gold_export
|
||||
172.24.49.21:/silver_platinum
|
||||
|
||||
@ -129,10 +129,9 @@ Configuring the array
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
enabled_backends = pool-a,pool-b
|
||||
default_volume_type = lenovo
|
||||
...
|
||||
|
||||
#. Create a new volume type for each distinct ``volume_backend_name`` value
|
||||
that you added to the ``cinder.conf`` file. The example below
|
||||
|
||||
@ -123,7 +123,7 @@ volume driver controls:
|
||||
Add your list of Nexenta NFS servers to the file you specified with the
|
||||
``nexenta_shares_config`` option. For example, this is how this file should look:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
192.168.1.200:/volumes/VOLUME_NAME/NFS_SHARE http://USER:PASSWORD@192.168.1.200:8457
|
||||
192.168.1.201:/volumes/VOLUME_NAME/NFS_SHARE http://USER:PASSWORD@192.168.1.201:8457
|
||||
|
||||
@ -124,7 +124,7 @@ volume driver controls:
|
||||
|
||||
#. Create filesystem on appliance and share via NFS. For example:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
"securityContexts": [
|
||||
{"readWriteList": [{"allow": true, "etype": "fqnip", "entity": "1.1.1.1"}],
|
||||
@ -133,7 +133,7 @@ volume driver controls:
|
||||
|
||||
#. Create ACL for the filesystem. For example:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: json
|
||||
|
||||
{"type": "allow",
|
||||
"principal": "everyone@",
|
||||
|
||||
@ -293,7 +293,7 @@ environments using the driver filter and weighter methods.
|
||||
|
||||
Metrics reported include, but are not limited to:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
total_capacity_gb
|
||||
free_capacity_gb
|
||||
|
||||
@ -103,7 +103,7 @@ Configuration
|
||||
|
||||
Target interfaces can be seen as follows in the CLI:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
zfssa:> configuration net interfaces
|
||||
zfssa:configuration net interfaces> show
|
||||
|
||||
@ -128,10 +128,9 @@ Configuring the array
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
enabled_backends = pool-a,pool-b
|
||||
default_volume_type = zte
|
||||
...
|
||||
|
||||
#. Create a new volume type for each distinct ``volume_backend_name`` value
|
||||
that you added to the ``cinder.conf`` file. The example below
|
||||
|
||||
@ -5,6 +5,6 @@ api-paste.ini
|
||||
Use the ``api-paste.ini`` file to configure the Block Storage API
|
||||
service.
|
||||
|
||||
.. remote-code-block:: ini
|
||||
.. remote-code-block:: none
|
||||
|
||||
https://git.openstack.org/cgit/openstack/cinder/plain/etc/cinder/api-paste.ini?h=stable/newton
|
||||
|
||||
@ -5,6 +5,6 @@ policy.json
|
||||
The ``policy.json`` file defines additional access controls that apply
|
||||
to the Block Storage service.
|
||||
|
||||
.. remote-code-block:: ini
|
||||
.. remote-code-block:: none
|
||||
|
||||
https://git.openstack.org/cgit/openstack/cinder/plain/etc/cinder/policy.json?h=stable/newton
|
||||
|
||||
@ -78,7 +78,7 @@ in the ``cell_type`` key:
|
||||
|
||||
[DEFAULT]
|
||||
compute_api_class=nova.compute.cells_api.ComputeCellsAPI
|
||||
...
|
||||
# ...
|
||||
|
||||
[cells]
|
||||
cell_type= api
|
||||
|
||||
@ -66,7 +66,7 @@ http://technet.microsoft.com/en-us/library/hh831823.aspx
|
||||
To quickly enable an interface to be used as a Virtual Interface the
|
||||
following PowerShell may be used:
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> $if = Get-NetIPAddress -IPAddress 192* | Get-NetIPInterface
|
||||
PS C:\> New-VMSwitch -NetAdapterName $if.ifAlias -Name YOUR_BRIDGE_NAME -AllowManagementOS $false
|
||||
@ -84,7 +84,7 @@ To prepare the Hyper-V node to be able to attach to volumes provided by
|
||||
cinder you must first make sure the Windows iSCSI initiator service is
|
||||
running and started automatically.
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> Set-Service -Name MSiSCSI -StartupType Automatic
|
||||
PS C:\> Start-Service MSiSCSI
|
||||
@ -147,10 +147,10 @@ Additional Requirements:
|
||||
How to setup live migration on Hyper-V
|
||||
--------------------------------------
|
||||
|
||||
To enable 'shared nothing live' migration, run the 3 PowerShell
|
||||
To enable 'shared nothing live' migration, run the 3
|
||||
instructions below on each Hyper-V host:
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> Enable-VMMigration
|
||||
PS C:\> Set-VMMigrationNetwork IP_ADDRESS
|
||||
@ -203,7 +203,7 @@ working properly on the 64bit version.
|
||||
|
||||
http://www.python.org/ftp/python/2.7.3/python-2.7.3.msi
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> $src = "http://www.python.org/ftp/python/2.7.3/python-2.7.3.msi"
|
||||
PS C:\> $dest = "$env:temp\python-2.7.3.msi"
|
||||
@ -214,7 +214,7 @@ working properly on the 64bit version.
|
||||
#. Make sure that the ``Python`` and ``Python\Scripts`` paths are set up
|
||||
in the ``PATH`` environment variable.
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> $oldPath = [System.Environment]::GetEnvironmentVariable("Path")
|
||||
PS C:\> $newPath = $oldPath + ";C:\python27\;C:\python27\Scripts\"
|
||||
@ -249,7 +249,7 @@ The following packages must be installed with pip:
|
||||
* amqp
|
||||
* wmi
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> pip install ecdsa
|
||||
PS C:\> pip install amqp
|
||||
@ -292,7 +292,7 @@ Download the nova code
|
||||
run the installer and follow the prompts in the installation wizard.
|
||||
The default should be acceptable for the purposes of this guide.
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> $src = "https://github.com/msysgit/msysgit/releases/download/Git-1.9.2-preview20140411/Git-1.9.2-preview20140411.exe"
|
||||
PS C:\> $dest = "$env:temp\Git-1.9.2-preview20140411.exe"
|
||||
@ -302,7 +302,7 @@ Download the nova code
|
||||
|
||||
#. Run the following to clone the nova code.
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> git.exe clone https://git.openstack.org/openstack/nova
|
||||
|
||||
@ -311,7 +311,7 @@ Install nova-compute service
|
||||
|
||||
To install ``nova-compute``, run:
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> cd c:\nova
|
||||
PS C:\> python setup.py install
|
||||
@ -387,7 +387,7 @@ http://technet.microsoft.com/en-us/library/cc772480.aspx
|
||||
Once you have successfully created a virtual machine, you can then upload
|
||||
the image to glance using the openstack-client:
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> openstack image create --name "VM_IMAGE_NAME" --public \
|
||||
--container-format bare --disk-format vhd
|
||||
@ -399,7 +399,7 @@ the image to glance using the openstack-client:
|
||||
disk size than the internal size of the disk file.
|
||||
To create VHDs, use the following PowerShell cmdlet:
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> New-VHD DISK_NAME.vhd -SizeBytes VHD_SIZE
|
||||
|
||||
@ -423,7 +423,7 @@ Run Compute with Hyper-V
|
||||
To start the ``nova-compute`` service, run this command from a console
|
||||
in the Windows server:
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> C:\Python27\python.exe c:\Python27\Scripts\nova-compute --config-file c:\etc\nova\nova.conf
|
||||
|
||||
@ -440,12 +440,12 @@ Troubleshoot Hyper-V configuration
|
||||
|
||||
* How do I restart the compute service?
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> net stop nova-compute && net start nova-compute
|
||||
|
||||
* How do I restart the iSCSI initiator service?
|
||||
|
||||
.. code-block:: powershell
|
||||
.. code-block:: none
|
||||
|
||||
PS C:\> net stop msiscsi && net start msiscsi
|
||||
|
||||
@ -44,8 +44,8 @@ This example ``nova.conf`` file is from an internal Rackspace test system.
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
verbose
|
||||
nodaemon
|
||||
verbose=True
|
||||
nodaemon=True
|
||||
network_manager=nova.network.manager.FlatManager
|
||||
image_service=nova.image.glance.GlanceImageService
|
||||
flat_network_bridge=xenbr0
|
||||
|
||||
@ -5,6 +5,6 @@ api-paste.ini
|
||||
The Compute service stores its API configuration settings in the
|
||||
``api-paste.ini`` file.
|
||||
|
||||
.. remote-code-block:: ini
|
||||
.. remote-code-block:: none
|
||||
|
||||
https://git.openstack.org/cgit/openstack/nova/plain/etc/nova/api-paste.ini
|
||||
|
||||
@ -432,7 +432,7 @@ To enable scheduling instances while overcommitting disk resources on the
|
||||
node, adjust the value of the ``disk_allocation_ratio`` configuration
|
||||
option to greater than ``1.0``:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
disk_allocation_ratio > 1.0
|
||||
|
||||
|
||||
@ -7,6 +7,6 @@ Configuration for the Image service's API middleware pipeline is found in the
|
||||
|
||||
You should not need to modify this file.
|
||||
|
||||
.. remote-code-block:: ini
|
||||
.. remote-code-block:: none
|
||||
|
||||
https://git.openstack.org/cgit/openstack/glance/plain/etc/glance-api-paste.ini?h=stable/newton
|
||||
|
||||
@ -5,6 +5,6 @@ api-paste.ini
|
||||
The ``api-paste.ini`` file contains configuration for the web services
|
||||
gateway interface (WSGI).
|
||||
|
||||
.. remote-code-block:: ini
|
||||
.. remote-code-block:: none
|
||||
|
||||
https://git.openstack.org/cgit/openstack/neutron/plain/etc/api-paste.ini?h=stable/newton
|
||||
|
||||
@ -383,7 +383,7 @@ production environment with many devices the impact of one device change is
|
||||
much less. Next, run the replicators to get everything put back into place and
|
||||
then rerun the dispersion report:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: none
|
||||
|
||||
# start object replicators and monitor logs until they're caught up ...
|
||||
$ swift-dispersion-report
|
||||
|
||||
@ -46,7 +46,7 @@ Examples
|
||||
|
||||
A simple rule might look like this:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"compute:get_all" : ""
|
||||
|
||||
@ -56,7 +56,7 @@ policy allows anybody to list instances.
|
||||
|
||||
You can also decline permission to use an API:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"compute:shelve": "!"
|
||||
|
||||
@ -67,7 +67,7 @@ Many APIs can only be called by admin users. This can be expressed by
|
||||
the rule ``"role:admin"``. The following policy ensures that only
|
||||
administrators can create new users in the Identity database:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"identity:create_user" : "role:admin"
|
||||
|
||||
@ -75,7 +75,7 @@ You can limit APIs to any role. For example, the Orchestration service
|
||||
defines a role named ``heat_stack_user``. Whoever has this role isn't
|
||||
allowed to create stacks:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"stacks:create": "not role:heat_stack_user"
|
||||
|
||||
@ -84,7 +84,7 @@ can be built using operators ``and``, ``or`` and parentheses.
|
||||
|
||||
You can define aliases for rules:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"deny_stack_user": "not role:heat_stack_user"
|
||||
|
||||
@ -92,7 +92,7 @@ The policy engine understands that ``"deny_stack_user"`` is not an API
|
||||
and consequently interprets it as an alias. The stack creation policy
|
||||
above can then be written as:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"stacks:create": "rule:deny_stack_user"
|
||||
|
||||
@ -100,7 +100,7 @@ This is taken verbatim from ``/etc/heat/policy.json``.
|
||||
|
||||
Rules can compare API attributes to object attributes. For example:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"os_compute_api:servers:start" : "project_id:%(project_id)s"
|
||||
|
||||
@ -114,7 +114,7 @@ equal, permission is granted.
|
||||
An admin user always has permission to call APIs. This is how
|
||||
``/etc/keystone/policy.json`` makes this policy explicit:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"admin_required": "role:admin or is_admin:1",
|
||||
"owner" : "user_id:%(user_id)s",
|
||||
@ -138,7 +138,7 @@ owner or an admin user.
|
||||
|
||||
As a final example, let's examine a more complex rule:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"identity:ec2_delete_credential": "rule:admin_required or
|
||||
(rule:owner and user_id:%(target.credential.user_id)s)"
|
||||
@ -158,7 +158,7 @@ A ``policy.json`` file consists of policies and aliases of the form
|
||||
``target:rule`` or ``alias:definition``, separated by commas and
|
||||
enclosed in curly braces:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
{
|
||||
"alias 1" : "definition 1",
|
||||
@ -201,7 +201,7 @@ Developers can define additional special checks.
|
||||
|
||||
Two values are compared in the following way:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"value1 : value2"
|
||||
|
||||
@ -232,7 +232,7 @@ The alias construct exists for convenience. An alias is short name for a
|
||||
complex or hard to understand rule. It is defined in the same way as a
|
||||
policy:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
alias name : alias definition
|
||||
|
||||
@ -247,7 +247,7 @@ syntax, where JavaScript arrays are used instead of boolean operators.
|
||||
For example, the EC2 credentials rule above would have been written as
|
||||
follows:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
"identity:ec2_delete_credential": [ [ "rule:admin_required ],
|
||||
[ "rule:owner", "user_id:%(target.credential.user_id)s)" ] ]
|
||||
|
||||
@ -42,7 +42,7 @@ The configuration for all of them follows a common paradigm:
|
||||
.. code-block:: ini
|
||||
|
||||
[Default]
|
||||
...
|
||||
# ...
|
||||
enabled_backends = Driver1 Driver2
|
||||
|
||||
#. Configure a separate section for each driver using these
|
||||
@ -54,11 +54,11 @@ The configuration for all of them follows a common paradigm:
|
||||
|
||||
[Driver1]
|
||||
share_driver = manila.share.drivers.generic.GenericShareDriver
|
||||
...
|
||||
# ...
|
||||
|
||||
[Driver2]
|
||||
share_driver = manila.share.drivers.generic.GenericShareDriver
|
||||
...
|
||||
# ...
|
||||
|
||||
The share drivers are included in the `Shared File Systems repository
|
||||
<https://git.openstack.org/cgit/openstack/manila/tree/manila/share/drivers>`_.
|
||||
|
||||
@ -112,10 +112,10 @@ Back end configuration
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
enabled_share_backends = hsp1
|
||||
enabled_share_protocols = NFS
|
||||
...
|
||||
# ...
|
||||
|
||||
[hsp1]
|
||||
share_backend_name = HITACHI1
|
||||
|
||||
@ -9,6 +9,6 @@ This file provides a standard set of events and corresponding traits
|
||||
that may be of interest. This file can be modified to add and drop
|
||||
traits that operators may find useful.
|
||||
|
||||
.. remote-code-block:: ini
|
||||
.. remote-code-block:: yaml
|
||||
|
||||
https://git.openstack.org/cgit/openstack/ceilometer/plain/etc/ceilometer/event_definitions.yaml?h=stable/newton
|
||||
|
||||
@ -9,6 +9,6 @@ defined in the ``event_pipeline.yaml`` file.
|
||||
This file can be modified to adjust which notifications to capture and
|
||||
where to publish the events.
|
||||
|
||||
.. remote-code-block:: ini
|
||||
.. remote-code-block:: yaml
|
||||
|
||||
https://git.openstack.org/cgit/openstack/ceilometer/plain/etc/ceilometer/event_pipeline.yaml?h=stable/newton
|
||||
|
||||
@ -9,6 +9,6 @@ are defined in the ``pipeline.yaml`` file.
|
||||
This file can be modified to adjust polling intervals and the samples
|
||||
generated by the Telemetry module.
|
||||
|
||||
.. remote-code-block:: ini
|
||||
.. remote-code-block:: yaml
|
||||
|
||||
https://git.openstack.org/cgit/openstack/ceilometer/plain/etc/ceilometer/pipeline.yaml?h=stable/newton
|
||||
|
||||
@ -44,7 +44,7 @@ You can configure the text editor to do that automatically.
|
||||
|
||||
For example, in the :file:`.vimrc`:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: vim
|
||||
|
||||
set list
|
||||
set listchars=tab:>-,trail:-,extends:#,nbsp:-
|
||||
|
||||
@ -19,7 +19,7 @@ To insert a semantic markup into your document, use the syntax below.
|
||||
|
||||
**Syntax**
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: rst
|
||||
|
||||
:markup:`inline text`
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ syntax format.
|
||||
|
||||
* The ``code-block`` tags should be closed with ``end``.
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: rst
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -39,7 +39,7 @@ syntax format.
|
||||
|
||||
* Example 1: Run a specific command from a given folder.
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: rst
|
||||
|
||||
.. path /usr/local/
|
||||
.. code-block:: console
|
||||
@ -53,7 +53,7 @@ syntax format.
|
||||
|
||||
* Example 2: Configure a configuration file.
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
.. path /etc/keystone/keystone.conf
|
||||
.. code-block:: ini
|
||||
@ -68,7 +68,7 @@ syntax format.
|
||||
|
||||
* The ``only`` tags should be closed with ``endonly``.
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
.. only:: ubuntu or debian
|
||||
|
||||
|
||||
@ -144,7 +144,7 @@ content from a remote URL (``http`` or ``https``).
|
||||
|
||||
**Output**
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: yaml
|
||||
|
||||
############
|
||||
# Metadata #
|
||||
|
||||
@ -68,7 +68,7 @@ Each section should follow this format:
|
||||
* A link with detailed instructions to the vendor site (if there is one).
|
||||
* A default paragraph, for example:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: rst
|
||||
|
||||
Set the following in your ``cinder.conf``, and use the following options
|
||||
to configure it.
|
||||
|
||||
@ -114,10 +114,10 @@ Configure OpenStack Identity service
|
||||
|
||||
[catalog]
|
||||
driver = keystone.catalog.backends.sql.Catalog
|
||||
...
|
||||
# ...
|
||||
[identity]
|
||||
driver = keystone.identity.backends.sql.Identity
|
||||
...
|
||||
# ...
|
||||
|
||||
#. If the Identity service will be sending ceilometer notifications
|
||||
and your message bus is configured for high availability, you will
|
||||
|
||||
@ -96,7 +96,7 @@ Set up the cluster with pcs
|
||||
|
||||
.. note::
|
||||
|
||||
The :option:`-p` option is used to give the password on command
|
||||
The ``-p`` option is used to give the password on command
|
||||
line and makes it easier to script.
|
||||
|
||||
#. Create and name the cluster, and then start it:
|
||||
@ -142,7 +142,7 @@ the Corosync package. An example Corosync configuration file is shown below:
|
||||
|
||||
**Example Corosync configuration file for multicast (``corosync.conf``)**
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
totem {
|
||||
version: 2
|
||||
@ -279,7 +279,7 @@ Note the following:
|
||||
configuration file ``/etc/corosync/uidgid.d/pacemaker``
|
||||
to be created with the following content:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
uidgid {
|
||||
uid: hacluster
|
||||
@ -301,7 +301,7 @@ for unicastis is shown below:
|
||||
|
||||
**Corosync configuration file fragment for unicast (``corosync.conf``)**
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
totem {
|
||||
#...
|
||||
@ -403,7 +403,7 @@ disk-based quorum daemon for CMAN, from advanced cluster configurations.
|
||||
|
||||
A sample votequorum service configuration in the :file:`corosync.conf` file is:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
quorum {
|
||||
provider: corosync_votequorum (1)
|
||||
@ -479,7 +479,7 @@ a Systemd unit file.
|
||||
|
||||
You can now check the ``corosync`` connectivity with one of these tools.
|
||||
|
||||
Use the :command:`corosync-cfgtool` utility with the :option:`-s` option
|
||||
Use the :command:`corosync-cfgtool` utility with the ``-s`` option
|
||||
to get a summary of the health of the communication rings:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -208,7 +208,7 @@ use the ``clustercheck`` utility to improve health checks.
|
||||
#. Create a configuration file for the HAProxy monitor service, at
|
||||
``/etc/xinetd.d/galera-monitor``:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
service galera-monitor
|
||||
{
|
||||
|
||||
@ -83,7 +83,7 @@ For SLES 12:
|
||||
For SLES 12, the packages are signed by GPG key 893A90DAD85F9316.
|
||||
You should verify the fingerprint of the imported GPG key before using it.
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
Key ID: 893A90DAD85F9316
|
||||
Key Name: Cloud:OpenStack OBS Project <Cloud:OpenStack@build.opensuse.org>
|
||||
|
||||
@ -67,7 +67,7 @@ You can now add the Pacemaker configuration for Block Storage API resource.
|
||||
Connect to the Pacemaker cluster with the :command:`crm configure` command
|
||||
and add the following cluster resources:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
primitive p_cinder-api ocf:openstack:cinder-api \
|
||||
params config="/etc/cinder/cinder.conf" \
|
||||
|
||||
@ -42,7 +42,7 @@ Add Shared File Systems API resource to Pacemaker
|
||||
|
||||
#. Add the following cluster resources:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
primitive p_manila-api ocf:openstack:manila-api \
|
||||
params config="/etc/manila/manila.conf" \
|
||||
|
||||
@ -120,9 +120,9 @@ configuration in your :file:`nova.conf` file:
|
||||
.. code-block:: ini
|
||||
|
||||
[glance]
|
||||
...
|
||||
# ...
|
||||
api_servers = 10.0.0.11
|
||||
...
|
||||
# ...
|
||||
|
||||
|
||||
You must also create the OpenStack Image API endpoint with this IP address.
|
||||
|
||||
@ -325,7 +325,7 @@ on CentOS 7.``x``, you might need to do the following steps:
|
||||
``GRUB_CMDLINE_LINUX`` option. Delete the ``rhgb quiet``
|
||||
and add the ``console=tty0 console=ttyS0,115200n8`` to the option:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: none
|
||||
|
||||
...
|
||||
GRUB_CMDLINE_LINUX="crashkernel=auto console=tty0 console=ttyS0,115200n8"
|
||||
|
||||
@ -208,7 +208,7 @@ with a different user. For example, to configure ``cloud-init``
|
||||
to put the key in an account named ``admin``, edit the
|
||||
configuration file so it has the line:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: yaml
|
||||
|
||||
user: admin
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ Install and configure components
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
my_ip = 10.0.0.11
|
||||
|
||||
Configure Compute to use Block Storage
|
||||
|
||||
@ -62,7 +62,7 @@ storage node, you must prepare the storage device.
|
||||
``/dev/sdb`` device and rejects all other devices:
|
||||
|
||||
.. path /etc/lvm/lvm.conf
|
||||
.. code-block:: ini
|
||||
.. code-block:: bash
|
||||
|
||||
devices {
|
||||
...
|
||||
@ -128,7 +128,7 @@ Install and configure components
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
my_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
|
||||
|
||||
.. end
|
||||
@ -145,7 +145,7 @@ Install and configure components
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
glance_api_servers = http://controller:9292
|
||||
|
||||
.. end
|
||||
|
||||
@ -86,7 +86,7 @@ rights, and create the database for you. Since OpenStack 2014.1.1, all
|
||||
OpenStack packages in Debian are performing the following MySQL query
|
||||
after database creation (if you decide to use MySQL as a back-end):
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: mysql
|
||||
|
||||
ALTER DATABASE keystone CHARACTER SET utf8 COLLATE utf8_unicode_ci
|
||||
|
||||
|
||||
@ -43,7 +43,7 @@ The following screens show an example Image service configuration:
|
||||
This information is stored in the configuration file for each service.
|
||||
For example:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: bash
|
||||
|
||||
/etc/ceilometer/ceilometer.conf
|
||||
/etc/nova/api-paste.ini
|
||||
|
||||
@ -23,7 +23,7 @@ Install and configure the components
|
||||
.. code-block:: ini
|
||||
|
||||
[database]
|
||||
...
|
||||
# ...
|
||||
connection = mysql+pymysql://keystone:KEYSTONE_DBPASS@controller/keystone
|
||||
|
||||
If you decide to not use ``dbconfig-common``, then you have to
|
||||
@ -56,7 +56,7 @@ Install and configure the components
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
admin_token = ADMIN_TOKEN
|
||||
|
||||
#. Create the ``admin`` project and user:
|
||||
|
||||
@ -38,7 +38,7 @@ Configure the server component
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
service_plugins =
|
||||
|
||||
* In the ``[DEFAULT]`` and ``[nova]`` sections, configure Networking to
|
||||
@ -47,12 +47,12 @@ Configure the server component
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
notify_nova_on_port_status_changes = True
|
||||
notify_nova_on_port_data_changes = True
|
||||
|
||||
[nova]
|
||||
...
|
||||
# ...
|
||||
auth_url = http://controller:35357
|
||||
auth_type = password
|
||||
project_domain_name = default
|
||||
@ -79,7 +79,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2]
|
||||
...
|
||||
# ...
|
||||
type_drivers = flat,vlan
|
||||
|
||||
* In the ``[ml2]`` section, disable self-service networks:
|
||||
@ -87,7 +87,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2]
|
||||
...
|
||||
# ...
|
||||
tenant_network_types =
|
||||
|
||||
* In the ``[ml2]`` section, enable the Linux bridge mechanism:
|
||||
@ -95,7 +95,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2]
|
||||
...
|
||||
# ...
|
||||
mechanism_drivers = linuxbridge
|
||||
|
||||
.. warning::
|
||||
@ -108,7 +108,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2]
|
||||
...
|
||||
# ...
|
||||
extension_drivers = port_security
|
||||
|
||||
* In the ``[ml2_type_flat]`` section, configure the provider virtual
|
||||
@ -117,7 +117,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2_type_flat]
|
||||
...
|
||||
# ...
|
||||
flat_networks = provider
|
||||
|
||||
* In the ``[securitygroup]`` section, enable :term:`ipset` to increase
|
||||
@ -126,7 +126,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[securitygroup]
|
||||
...
|
||||
# ...
|
||||
enable_ipset = True
|
||||
|
||||
Configure the Linux bridge agent
|
||||
@ -163,7 +163,7 @@ networking infrastructure for instances and handles security groups.
|
||||
.. code-block:: ini
|
||||
|
||||
[securitygroup]
|
||||
...
|
||||
# ...
|
||||
enable_security_group = True
|
||||
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
|
||||
|
||||
@ -182,7 +182,7 @@ The :term:`DHCP agent` provides DHCP services for virtual networks.
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
interface_driver = linuxbridge
|
||||
dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
|
||||
enable_isolated_metadata = True
|
||||
|
||||
@ -43,7 +43,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2]
|
||||
...
|
||||
# ...
|
||||
type_drivers = flat,vlan,vxlan
|
||||
|
||||
* In the ``[ml2]`` section, enable VXLAN self-service networks:
|
||||
@ -51,7 +51,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2]
|
||||
...
|
||||
# ...
|
||||
tenant_network_types = vxlan
|
||||
|
||||
* In the ``[ml2]`` section, enable the Linux bridge and layer-2 population
|
||||
@ -60,7 +60,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2]
|
||||
...
|
||||
# ...
|
||||
mechanism_drivers = linuxbridge,l2population
|
||||
|
||||
.. warning::
|
||||
@ -77,7 +77,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2]
|
||||
...
|
||||
# ...
|
||||
extension_drivers = port_security
|
||||
|
||||
* In the ``[ml2_type_flat]`` section, configure the provider virtual
|
||||
@ -86,7 +86,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2_type_flat]
|
||||
...
|
||||
# ...
|
||||
flat_networks = provider
|
||||
|
||||
* In the ``[ml2_type_vxlan]`` section, configure the VXLAN network identifier
|
||||
@ -95,7 +95,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[ml2_type_vxlan]
|
||||
...
|
||||
# ...
|
||||
vni_ranges = 1:1000
|
||||
|
||||
* In the ``[securitygroup]`` section, enable :term:`ipset` to increase
|
||||
@ -104,7 +104,7 @@ and switching) virtual networking infrastructure for instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[securitygroup]
|
||||
...
|
||||
# ...
|
||||
enable_ipset = True
|
||||
|
||||
Configure the Linux bridge agent
|
||||
@ -152,7 +152,7 @@ networking infrastructure for instances and handles security groups.
|
||||
.. code-block:: ini
|
||||
|
||||
[securitygroup]
|
||||
...
|
||||
# ...
|
||||
enable_security_group = True
|
||||
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
|
||||
|
||||
@ -171,7 +171,7 @@ self-service virtual networks.
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
interface_driver = linuxbridge
|
||||
external_network_bridge =
|
||||
|
||||
@ -195,7 +195,7 @@ The :term:`DHCP agent` provides DHCP services for virtual networks.
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
interface_driver = linuxbridge
|
||||
dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
|
||||
enable_isolated_metadata = True
|
||||
|
||||
@ -59,7 +59,7 @@ such as credentials to instances.
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
nova_metadata_ip = controller
|
||||
metadata_proxy_shared_secret = METADATA_SECRET
|
||||
|
||||
@ -76,7 +76,7 @@ Configure the Compute service to use the Networking service
|
||||
.. code-block:: ini
|
||||
|
||||
[neutron]
|
||||
...
|
||||
# ...
|
||||
url = http://controller:9696
|
||||
auth_url = http://controller:35357
|
||||
auth_type = password
|
||||
|
||||
@ -49,7 +49,7 @@ Install and configure components
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
my_ip = MANAGEMENT_INTERFACE_IP_ADDRESS
|
||||
|
||||
Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address
|
||||
@ -62,7 +62,7 @@ Install and configure components
|
||||
.. code-block:: ini
|
||||
|
||||
[vnc]
|
||||
...
|
||||
# ...
|
||||
enabled = True
|
||||
vncserver_listen = 0.0.0.0
|
||||
vncserver_proxyclient_address = $my_ip
|
||||
@ -87,7 +87,7 @@ Install and configure components
|
||||
.. code-block:: ini
|
||||
|
||||
[glance]
|
||||
...
|
||||
# ...
|
||||
api_servers = http://controller:9292
|
||||
|
||||
#. Ensure the kernel module ``nbd`` is loaded.
|
||||
|
||||
@ -46,7 +46,7 @@ Install and configure components
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
enabled_apis = osapi_compute,metadata
|
||||
|
||||
* The ``.config`` and ``.postinst`` maintainer scripts of the
|
||||
@ -58,7 +58,7 @@ Install and configure components
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
my_ip = 10.0.0.11
|
||||
|
||||
* In the ``[DEFAULT]`` section, enable support for the Networking service:
|
||||
@ -66,7 +66,7 @@ Install and configure components
|
||||
.. code-block:: ini
|
||||
|
||||
[DEFAULT]
|
||||
...
|
||||
# ...
|
||||
use_neutron = True
|
||||
firewall_driver = nova.virt.firewall.NoopFirewallDriver
|
||||
|
||||
@ -84,7 +84,7 @@ Install and configure components
|
||||
|
||||
[vnc]
|
||||
enabled = true
|
||||
...
|
||||
# ...
|
||||
vncserver_listen = $my_ip
|
||||
vncserver_proxyclient_address = $my_ip
|
||||
|
||||
@ -102,7 +102,7 @@ Install and configure components
|
||||
.. code-block:: ini
|
||||
|
||||
[glance]
|
||||
...
|
||||
# ...
|
||||
api_servers = http://controller:9292
|
||||
|
||||
Finalize installation
|
||||
|
||||
@ -364,7 +364,7 @@ Install and configure components
|
||||
3. Create the ``/etc/tgt/conf.d/cinder.conf`` file
|
||||
with the following data:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: shell
|
||||
|
||||
include /var/lib/cinder/volumes/*
|
||||
|
||||
|
||||
@ -24,7 +24,7 @@ Configure network interfaces
|
||||
* Edit the ``/etc/network/interfaces`` file to contain the following:
|
||||
|
||||
.. path /etc/network/interfaces
|
||||
.. code-block:: ini
|
||||
.. code-block:: bash
|
||||
|
||||
# The provider network interface
|
||||
auto INTERFACE_NAME
|
||||
|
||||
@ -45,7 +45,7 @@ Install and configure components
|
||||
2. Edit the ``/etc/chrony/chrony.conf`` file and add, change, or remove
|
||||
these keys as necessary for your environment:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: shell
|
||||
|
||||
server NTP_SERVER iburst
|
||||
|
||||
@ -64,7 +64,7 @@ Install and configure components
|
||||
3. To enable other nodes to connect to the chrony daemon on the controller node,
|
||||
add this key to the ``/etc/chrony/chrony.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: shell
|
||||
|
||||
allow 10.0.0.0/24
|
||||
|
||||
@ -85,7 +85,7 @@ Install and configure components
|
||||
2. Edit the ``/etc/chrony.conf`` file and add, change, or remove these
|
||||
keys as necessary for your environment:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: shell
|
||||
|
||||
server NTP_SERVER iburst
|
||||
|
||||
@ -104,7 +104,7 @@ Install and configure components
|
||||
3. To enable other nodes to connect to the chrony daemon on the controller node,
|
||||
add this key to the ``/etc/chrony.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: shell
|
||||
|
||||
allow 10.0.0.0/24
|
||||
|
||||
|
||||
@ -47,7 +47,7 @@ Install and configure components
|
||||
but one ``server`` key. Change it to reference the controller node:
|
||||
|
||||
.. path /etc/chrony/chrony.conf
|
||||
.. code-block:: ini
|
||||
.. code-block:: shell
|
||||
|
||||
server controller iburst
|
||||
|
||||
@ -71,7 +71,7 @@ Install and configure components
|
||||
``server`` key. Change it to reference the controller node:
|
||||
|
||||
.. path /etc/chrony.conf
|
||||
.. code-block:: ini
|
||||
.. code-block:: shell
|
||||
|
||||
server controller iburst
|
||||
|
||||
|
||||
@ -70,7 +70,7 @@ Install and configure components
|
||||
bind-address = 10.0.0.11
|
||||
|
||||
default-storage-engine = innodb
|
||||
innodb_file_per_table
|
||||
innodb_file_per_table = on
|
||||
max_connections = 4096
|
||||
collation-server = utf8_general_ci
|
||||
character-set-server = utf8
|
||||
@ -96,7 +96,7 @@ Install and configure components
|
||||
bind-address = 10.0.0.11
|
||||
|
||||
default-storage-engine = innodb
|
||||
innodb_file_per_table
|
||||
innodb_file_per_table = on
|
||||
max_connections = 4096
|
||||
collation-server = utf8_general_ci
|
||||
character-set-server = utf8
|
||||
@ -122,7 +122,7 @@ Install and configure components
|
||||
bind-address = 10.0.0.11
|
||||
|
||||
default-storage-engine = innodb
|
||||
innodb_file_per_table
|
||||
innodb_file_per_table = on
|
||||
max_connections = 4096
|
||||
collation-server = utf8_general_ci
|
||||
character-set-server = utf8
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user