Merge "Prepare for Sphinx 1.5"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
11f711ce0f
@ -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