openstack/openstack-manuals
Code Issues Proposed changes
a0f3e68f3a
openstack-manuals/doc/install-guide-debconf/source/neutron-controller-install.rst
Andreas Jaeger 2d44b2b36d 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
2017-01-11 20:37:55 +01:00

3.4 KiB
Raw Blame History

Install and configure controller node

Configure networking options

You can deploy the Networking service using one of two architectures represented by options 1 and 2.

Option 1 deploys the simplest possible architecture that only supports attaching instances to provider (external) networks. No self-service (private) networks, routers, or floating IP addresses. Only the admin or other privileged user can manage provider networks.

Option 2 augments option 1 with layer-3 services that support attaching instances to self-service networks. The demo or other unprivileged user can manage self-service networks including routers that provide connectivity between self-service and provider networks. Additionally, floating IP addresses provide connectivity to instances using self-service networks from external networks such as the Internet.

Self-service networks typically use overlay networks. Overlay network protocols such as VXLAN include additional headers that increase overhead and decrease space available for the payload or user data. Without knowledge of the virtual network infrastructure, instances attempt to send packets using the default Ethernet maximum transmission unit (MTU) of 1500 bytes. The Networking service automatically provides the correct MTU value to instances via DHCP. However, some cloud images do not use DHCP or ignore the DHCP MTU option and require configuration using metadata or a script.

Note

Option 2 also supports attaching instances to provider networks.

Choose one of the following networking options to configure services specific to it. Afterwards, return here and proceed to neutron-controller-metadata-agent.

neutron-controller-install-option1.rst neutron-controller-install-option2.rst

Configure the metadata agent

The metadata agent <Metadata agent> provides configuration information such as credentials to instances.

  • Edit the /etc/neutron/metadata_agent.ini file and complete the following actions:

    • In the [DEFAULT] section, configure the metadata host and shared secret:

      [DEFAULT]
# ...
nova_metadata_ip = controller
metadata_proxy_shared_secret = METADATA_SECRET

      Replace METADATA_SECRET with a suitable secret for the metadata proxy.

Configure the Compute service to use the Networking service

  • Edit the /etc/nova/nova.conf file and perform the following actions:

    • In the [neutron] section, configure access parameters, enable the metadata proxy, and configure the secret:

      [neutron]
# ...
url = http://controller:9696
auth_url = http://controller:35357
auth_type = password
project_domain_name = default
user_domain_name = default
region_name = RegionOne
project_name = service
username = neutron
password = NEUTRON_PASS

service_metadata_proxy = True
metadata_proxy_shared_secret = METADATA_SECRET

      Replace NEUTRON_PASS with the password you chose for the neutron user in the Identity service.

      Replace METADATA_SECRET with the secret you chose for the metadata proxy.