openstack
/
fuel-docs
Code Issues Proposed changes

Add network templates section 

Change-Id: Ia5b7670831fddeddb42a111b191f816c7b776c82
This commit is contained in:
Svetlana Karslioglu 2016-08-16 14:57:04 -07:00
parent adfebaf478
commit 000bd7709f
20 changed files with 1357 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
_templates/openstackdocs/theme.conf
View File

@ -4,6 +4,6 @@ stylesheet = css/basic.css
pygments_style = native
[options]
globaltoc_depth = 4
globaltoc_depth = 5
globaltoc_includehidden = true
analytics_tracking_code = UA-17511903-1

17
examples/network_templates.html Normal file
View File

@ -0,0 +1,17 @@
<!DOCTYPE html>
<html><head>
<title>network_templates</title>
</head>
<body>
<h1>network_templates</h1>
<a href="network_templates/ceph.yaml">ceph.yaml</a><br>
<a href="network_templates/cinder.yaml">cinder.yaml</a><br>
<a href="network_templates/cinder_add_nodes.yaml">cinder_add_nodes.yaml</a><br>
<a href="network_templates/default.yaml">default.yaml</a><br>
<a href="network_templates/hardware.yaml">hardware.yaml</a><br>
<a href="network_templates/one_network.yaml">one_network.yaml</a><br>
<a href="network_templates/two_networks.yaml">two_networks.yaml</a><br>
<a href="network_templates/two_nodegroups.yaml">two_nodegroups.yaml</a><br>
</body>
</html>

199
examples/network_templates/default.yaml Normal file
View File

@ -0,0 +1,199 @@
adv_net_template:
# default - is the name of the node network group. If you have additional
# node network groups, add descriptions with all parameters for all node
# network group.
# If parameters of additional node network groups are not described in this
# template, parameters of the default node network group apply.
default:
nic_mapping:
# NIC mapping for nodes in this node network group. The default section will
# be used for all nodes unless they are specifically configured. You can
# specify mapping for every node by the node name
default:
# Specify aliases for network interfaces, such as eth0, and
# sub-interfaces (VLANs), such as eth0.101 to
# later use them in the transformation section.
adm: eth0
pub: eth1
man: eth4
priv: eth2
stor: eth3
templates_for_node_role:
# Specify templates for each type of node (node role), such as controller,
# compute, storage, and so on. The order of templates
# is important. For example, if you create a bond in one template and later
# use it in the other template, you must place the template in which you
# created the bond before the other template, so that the bond is created
# before it is referenced in the other template.
controller:
- public
- private
- storage
- common
compute:
- common
- private
- storage
cinder:
- common
- storage
ceph-osd:
- common
- storage
network_assignments:
# Specify an endpoint for each network, if you add additional custom networks,
# add endpoints for these networks as well.
storage:
ep: br-storage
private:
ep: br-prv
public:
ep: br-ex
management:
ep: br-mgmt
fuelweb_admin:
ep: br-fw-admin
network_scheme:
# Describe the network scheme for all node roles.
# - transformations - describe actions required to create a network.
# For service networks, such as Storage, Management, and Admin,
# create a Linux bridge. For workload networks that
# communicated with the OpenStack Networking service, such as
# Private and Public service, create an Open vSwitch (OVS),
# a Linux Bridge, a patch that connects the OVS with the Linux
# bridge, and a port.
# Available commands:
#
# * ``add-br`` - creates a bridge. By default, creates a Linux
# bridge.
#
# * ``add-port`` - creates a port that connects a Linux bridge with a
# physical network interface.
#
# * ``add-patch`` - connects two network bridges. All networks that
# serve traffic to the control plane must have a patch that connects
# the OVS bridge and the Linux bridge.
#
# * ``add-bond`` - add a network interface bonding for high workload
# networks to increase performance and provide high availability.
#
# For more information about the properties that you can specify, see
# the Fuel User Guide: http://docs.openstack.org/developer/fuel-docs.html.
#
# - endpoints - specify the list of logical endpoints for the networks
# that you have defined in the network_assignments section.
#
# - roles - map network traffic (network roles) to logical endpoints in the
# <type_of_traffic>: <endpoint> format. The list of network roles is
# available in the nailgun/nailgun/fixtures/openstack.yaml file.
# Any type of traffic must be mentioned in the whole node network
# group just once, therefore, do not repeat any type of traffic in multiple
# entries. Otherwise, a network
# conflict may occur. The roles section cannot be empty. If you do not
# want to specify any type of traffic, create a fake mapping. For example:
# roles:
# fake/ext: br-pub-ext
#
# Plugins may have additional types of traffic. For more information, see
# plugin documentation.
#
storage:
transformations:
- action: add-br
name: br-storage
- action: add-port
bridge: br-storage
name: <% stor %>.1001
endpoints:
- br-storage
roles:
cinder/iscsi: br-storage
swift/replication: br-storage
ceph/replication: br-storage
storage: br-storage
private:
transformations:
- action: add-br
name: br-prv
provider: ovs
- action: add-br
name: br-aux
- action: add-patch
bridges:
- br-prv
- br-aux
provider: ovs
mtu: 65000
- action: add-port
bridge: br-aux
name: <% priv %>
endpoints:
- br-prv
roles:
neutron/private: br-prv
public:
transformations:
- action: add-br
name: br-ex
- action: add-br
name: br-floating
provider: ovs
- action: add-patch
bridges:
- br-floating
- br-ex
provider: ovs
mtu: 65000
- action: add-port
bridge: br-ex
name: <% pub %>
endpoints:
- br-ex
roles:
public/vip: br-ex
neutron/floating: br-floating
ceph/radosgw: br-ex
ex: br-ex
common:
# In this example, the common template is created for Management and
# Admin networks.
transformations:
- action: add-br
name: br-fw-admin
- action: add-port
bridge: br-fw-admin
name: <% adm %>
- action: add-br
name: br-mgmt
- action: add-port
bridge: br-mgmt
name: <% man %>
endpoints:
- br-fw-admin
- br-mgmt
roles:
admin/pxe: br-fw-admin
fw-admin: br-fw-admin
mongo/db: br-mgmt
management: br-mgmt
keystone/api: br-mgmt
neutron/api: br-mgmt
neutron/mesh: br-mgmt
swift/api: br-mgmt
sahara/api: br-mgmt
ceilometer/api: br-mgmt
cinder/api: br-mgmt
glance/api: br-mgmt
heat/api: br-mgmt
nova/api: br-mgmt
nova/migration: br-mgmt
murano/api: br-mgmt
horizon: br-mgmt
mgmt/api: br-mgmt
mgmt/memcache: br-mgmt
mgmt/database: br-mgmt
mgmt/messaging: br-mgmt
mgmt/corosync: br-mgmt
mgmt/vip: br-mgmt
mgmt/api: br-mgmt
ceph/public: br-mgmt

85
examples/network_templates/one_network.yaml Normal file
View File

@ -0,0 +1,85 @@
adv_net_template:
default:
network_assignments:
fuelweb_admin:
ep: br-fw-admin
network_scheme:
common:
endpoints:
- br-fw-admin
roles:
admin/pxe: br-fw-admin
ceilometer/api: br-fw-admin
ceph/public: br-fw-admin
cinder/api: br-fw-admin
fw-admin: br-fw-admin
glance/api: br-fw-admin
heat/api: br-fw-admin
horizon: br-fw-admin
keystone/api: br-fw-admin
management: br-fw-admin
mgmt/corosync: br-fw-admin
mgmt/database: br-fw-admin
mgmt/memcache: br-fw-admin
mgmt/messaging: br-fw-admin
mgmt/vip: br-fw-admin
mongo/db: br-fw-admin
murano/api: br-fw-admin
neutron/api: br-fw-admin
neutron/mesh: br-fw-admin
nova/api: br-fw-admin
nova/migration: br-fw-admin
sahara/api: br-fw-admin
swift/api: br-fw-admin
neutron/private: br-fw-admin
ceph/radosgw: br-fw-admin
ex: br-fw-admin
neutron/floating: br-floating
public/vip: br-fw-admin
ceph/replication: br-fw-admin
cinder/iscsi: br-fw-admin
storage: br-fw-admin
swift/replication: br-fw-admin
swift/public: br-fw-admin
transformations:
- action: add-br
name: br-fw-admin
- action: add-port
bridge: br-fw-admin
name: <% if1 %>
- action: add-br
name: br-aux
- action: add-br
name: br-prv
provider: ovs
- action: add-patch
bridges:
- br-prv
- br-fw-admin
mtu: 65000
provider: ovs
- action: add-br
name: br-floating
provider: ovs
- action: add-patch
bridges:
- br-floating
- br-fw-admin
mtu: 65000
provider: ovs
nic_mapping:
default:
if1: eth0
templates_for_node_role:
cinder:
- common
compute:
- common
controller:
- common
ceph-osd:
- common
mongo:
- common

93
examples/network_templates/two_networks.yaml Normal file
View File

@ -0,0 +1,93 @@
adv_net_template:
default:
network_assignments:
fuelweb_admin:
ep: br-fw-admin
everything:
ep: br-all
network_scheme:
common:
endpoints:
- br-all
- br-fw-admin
roles:
admin/pxe: br-fw-admin
ceilometer/api: br-all
ceph/public: br-all
cinder/api: br-all
fw-admin: br-fw-admin
glance/api: br-all
heat/api: br-all
horizon: br-all
keystone/api: br-all
management: br-all
mgmt/corosync: br-all
mgmt/database: br-all
mgmt/memcache: br-all
mgmt/messaging: br-all
mgmt/vip: br-all
mongo/db: br-all
murano/api: br-all
neutron/api: br-all
neutron/mesh: br-all
nova/api: br-all
nova/migration: br-all
sahara/api: br-all
swift/api: br-all
neutron/private: br-all
ceph/radosgw: br-all
ex: br-all
neutron/floating: br-floating
public/vip: br-all
ceph/replication: br-all
cinder/iscsi: br-all
storage: br-all
swift/replication: br-all
swift/public: br-all
transformations:
- action: add-br
name: br-fw-admin
- action: add-port
bridge: br-fw-admin
name: <% if1 %>
- action: add-br
name: br-all
- action: add-port
bridge: br-all
name: <% if2 %>
- action: add-br
name: br-aux
- action: add-br
name: br-prv
provider: ovs
- action: add-patch
bridges:
- br-prv
- br-all
mtu: 65000
provider: ovs
- action: add-br
name: br-floating
provider: ovs
- action: add-patch
bridges:
- br-floating
- br-all
mtu: 65000
provider: ovs
nic_mapping:
default:
if1: eth0
if2: eth1
templates_for_node_role:
cinder:
- common
compute:
- common
controller:
- common
ceph-osd:
- common
mongo:
- common

285
examples/network_templates/two_nodegroups.yaml Normal file
View File

@ -0,0 +1,285 @@
adv_net_template:
default:
nic_mapping:
default:
if11: eth0 # admin
if12: eth1 # public
if13: eth2 # management
if14: eth3 # private
if15: eth4 # storage
templates_for_node_role:
controller:
- admin
- public
- management
- private
- storage
compute:
- admin
- public
- management
- private
- storage
cinder:
- admin
- public
- management
- private
- storage
network_assignments:
storage:
ep: br-storage
private:
ep: br-prv
public:
ep: br-ex
management:
ep: br-mgmt
fuelweb_admin:
ep: br-fw-admin
network_scheme:
admin:
transformations:
- action: add-br
name: br-fw-admin
- action: add-port
bridge: br-fw-admin
name: eth0
endpoints:
- br-fw-admin
roles:
admin/pxe: br-fw-admin
fw-admin: br-fw-admin
public:
transformations:
- action: add-br
name: br-ex
- action: add-br
name: br-floating
provider: ovs
- action: add-patch
bridges:
- br-floating
- br-ex
provider: ovs
mtu: 65000
- action: add-port
bridge: br-ex
name: eth1
endpoints:
- br-ex
roles:
public/vip: br-ex
neutron/floating: br-ex
ex: br-ex
public: br-ex
management:
transformations:
- action: add-br
name: br-mgmt
- action: add-port
bridge: br-mgmt
name: eth2
endpoints:
- br-mgmt
roles:
management: br-mgmt
mgmt/vip: br-mgmt
mgmt/api: br-mgmt
mongo/db: br-mgmt
keystone/api: br-mgmt
neutron/api: br-mgmt
neutron/mesh: br-mgmt
swift/api: br-mgmt
sahara/api: br-mgmt
ceilometer/api: br-mgmt
cinder/api: br-mgmt
glance/api: br-mgmt
heat/api: br-mgmt
nova/api: br-mgmt
nova/migration: br-mgmt
murano/api: br-mgmt
horizon: br-mgmt
mgmt/messaging: br-mgmt
mgmt/corosync: br-mgmt
mgmt/memcache: br-mgmt
mgmt/database: br-mgmt
cinder/iscsi: br-mgmt
swift/replication: br-mgmt
ceph/replication: br-mgmt
ceph/radosgw: br-mgmt
private:
transformations:
- action: add-br
name: br-prv
provider: ovs
- action: add-br
name: br-aux
- action: add-patch
bridges:
- br-prv
- br-aux
provider: ovs
mtu: 65000
- action: add-port
bridge: br-aux
name: eth3
endpoints:
- br-prv
roles:
private: br-prv
neutron/private: br-prv
storage:
transformations:
- action: add-br
name: br-storage
- action: add-port
bridge: br-storage
name: eth4
endpoints:
- br-storage
roles:
storage: br-storage
ceph/public: br-storage
group-custom-1:
nic_mapping:
default:
if11: eth0 # admin
if12: eth1 # public
if13: eth2 # management
if14: eth3 # private
if15: eth4 # storage
templates_for_node_role:
controller:
- admin
- public
- management
- private
- storage
compute:
- admin
- public
- management
- private
- storage
cinder:
- admin
- public
- management
- private
- storage
network_assignments:
storage:
ep: br-storage
private:
ep: br-prv
public:
ep: br-ex
management:
ep: br-mgmt
fuelweb_admin:
ep: br-fw-admin
network_scheme:
admin:
transformations:
- action: add-br
name: br-fw-admin
- action: add-port
bridge: br-fw-admin
name: eth0
endpoints:
- br-fw-admin
roles:
admin/pxe: br-fw-admin
fw-admin: br-fw-admin
public:
transformations:
- action: add-br
name: br-ex
- action: add-br
name: br-floating
provider: ovs
- action: add-patch
bridges:
- br-floating
- br-ex
provider: ovs
mtu: 65000
- action: add-port
bridge: br-ex
name: eth1
endpoints:
- br-ex
roles:
public/vip: br-ex
neutron/floating: br-ex
ex: br-ex
public: br-ex
management:
transformations:
- action: add-br
name: br-mgmt
- action: add-port
bridge: br-mgmt
name: eth2
endpoints:
- br-mgmt
roles:
management: br-mgmt
mgmt/vip: br-mgmt
mgmt/api: br-mgmt
mongo/db: br-mgmt
keystone/api: br-mgmt
neutron/api: br-mgmt
neutron/mesh: br-mgmt
swift/api: br-mgmt
sahara/api: br-mgmt
ceilometer/api: br-mgmt
cinder/api: br-mgmt
glance/api: br-mgmt
heat/api: br-mgmt
nova/api: br-mgmt
nova/migration: br-mgmt
murano/api: br-mgmt
horizon: br-mgmt
mgmt/messaging: br-mgmt
mgmt/corosync: br-mgmt
mgmt/memcache: br-mgmt
mgmt/database: br-mgmt
cinder/iscsi: br-mgmt
swift/replication: br-mgmt
ceph/replication: br-mgmt
ceph/radosgw: br-mgmt
private:
transformations:
- action: add-br
name: br-prv
provider: ovs
- action: add-br
name: br-aux
- action: add-patch
bridges:
- br-prv
- br-aux
provider: ovs
mtu: 65000
- action: add-port
bridge: br-aux
name: eth3
endpoints:
- br-prv
roles:
private: br-prv
neutron/private: br-prv
storage:
transformations:
- action: add-br
name: br-storage
- action: add-port
bridge: br-storage
name: eth4
endpoints:
- br-storage
roles:
storage: br-storage
ceph/public: br-storage

3
userdocs/fuel-user-guide/configure-environment.rst
View File

@ -21,7 +21,7 @@ This section includes the following topics:
PageBreak
.. toctree::
:maxdepth: 3
:maxdepth: 1
configure-environment/add-nodes.rst
configure-environment/add-label.rst
@ -33,6 +33,7 @@ This section includes the following topics:
configure-environment/selectable-offload.rst
configure-environment/map-logical-to-physical-nic.rst
configure-environment/verify-networks.rst
configure-environment/network-templates.rst
configure-environment/customize-partitions.rst
configure-environment/config-drive-format.rst
configure-environment/settings.rst

31
userdocs/fuel-user-guide/configure-environment/network-templates.rst Normal file
View File

@ -0,0 +1,31 @@
.. _network-templates-intro:
Deploy network configurations using network templates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default, Fuel configures the following networks (Linux bridges): Public,
Private, Storage, Admin (PXE), and Management. In addition, if you install the
OpenStack Bare Metal service, Fuel creates the Baremetal network. If you need
to add a custom network or do not need any of the default networks, you can
configure or delete the required networks through network templates.
Network templates enable you to:
* Create a custom set of networks.
* Create mappings of network roles to networks.
* Use a network on a specific node only if a corresponding node role is
configured on the node
* Implement custom networking topologies, such as sub-interface bonding,
and so on.
This section includes the following topics:
.. toctree::
:maxdepth: 1
network-templates/network-templates-overview.rst
network-templates/network-templates-limitations.rst
network-templates/network-templates-structure.rst
network-templates/network-templates-create.rst
network-templates/network-templates-delete.rst
network-templates/network-templates-examples.rst

29
userdocs/fuel-user-guide/configure-environment/network-templates/examples/one-network.rst Normal file
View File

@ -0,0 +1,29 @@
.. _one-network:
Configure a single network topology
-----------------------------------
Fuel supports a single network configuration where one network serves
all OpenStack traffic. This configuration is common in
proof of concept deployments where no additional networks are
available.
**To configure a single network:**
#. Save `network template for one network
</./../network_templates/one_network.yaml>`_
as ``network_template_<env id>.yaml``.
#. Upload the network template by typing:
::
# fuel network-template --upload --env <env id>
#. Deploy the OpenStack environment.
#. Allocate the correct floating IP pool to the network.
#. Clear the gateway from `router04`.
#. Delete the `admin_floating_net__subnet` subnet.
#. Create a new subnet with the floating IP pool from the single network.
#. Set gateway on `router04`.

75
userdocs/fuel-user-guide/configure-environment/network-templates/examples/two-networks.rst Normal file
View File

@ -0,0 +1,75 @@
.. _two-networks:
Configure the two-network topology
----------------------------------
Fuel supports two-network configuration where one network is
dedicated for PXE traffic and another network for
all other traffic.
**To configure a two-network topology:**
1. Create a new network for all non-PXE traffic:
::
# fuel network-group --create --name everything --cidr <cidr>
--gateway <gateway> --nodegroup <nodegroup>
2. Set the ``render_addr_mask`` parameter to `internal` for this network by
typing:
::
# fuel network-group --set --network 39 --meta '{"name":
"everything", "notation": "cidr", "render_type": null, "map_priority": 2,
"configurable": true, "use_gateway": true, "render_addr_mask":
"internal", "vlan_start": null, "cidr": "10.108.31.0/24"}'
This parameter is required by the Fuel library. The Fuel library requires
a value called ``internal_address`` for each node.
This value is set to the node's IP address from a network group which has
``render_addr_mask`` set to `internal` in its metadata. Therefore, update
``render_addr_mask`` for this network.
3. Save `network template for two networks
</./../network_templates/two_networks.yaml>`_
as ``network_template_<env id>.yaml``.
.. note::
Verify that ``nic_mapping`` matches your configuration.
4. Upload the network template by typing:
::
# fuel network-template --upload --env <env id>
5. Deploy the environment.
6. After Fuel completes the deployment, verify that only one bridge is
configured by typing:
::
# ip -4 a
**Example of system output:**
::
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
8: br-fw-admin: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP group default
inet 10.108.5.3/24 brd 10.108.5.255 scope global br-fw-admin
valid_lft forever preferred_lft forever
16: vr-host-base: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP group default qlen 1000
inet 240.0.0.5/30 scope global vr-host-base
valid_lft forever preferred_lft forever
30: hapr-host: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
inet 240.0.0.1/30 scope global hapr-host
valid_lft forever preferred_lft forever

127
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-create.rst Normal file
View File

@ -0,0 +1,127 @@
.. _network-templates-create:
Create a network template
-------------------------
You can use one of the network templates provided in
:ref:`network-templates-examples`.
However, if these templates do not meet your networking requirements,
you can create your own. We strongly recommend that you use the
``default.yaml`` network template provided in this documentation to
build your own network template.
.. note::
When you configure a network using network templates, you cannot apply
changes to the nodes network configuration using the Fuel web UI. For
example, if you configure an OpenStack environment using network
templates, deploy the OpenStack environment, and later decide to add
new nodes, you must update network configuration of these nodes using
network templates and do not use the Fuel web-UI. However, templates do
not describe the level 2 and level 3 network settings. Therefore, you
must set them using Fuel web UI, CLI, or API.
After uploading a network template, you must create and/or
delete networks and node groups using the Fuel CLI to reflect the uploaded
network configuration. Otherwise, the configuration specified in the network
template will not take effect and may result in a malfunction.
**To create a network template:**
#. Create a ``.yaml`` file.
#. Specify your network configuration in the ``.yaml`` file following
the conventions described in :ref:`network-templates-structure`.
#. Log in to the Fuel Master node CLI.
#. Display the ID of the environment in which you want to upload the
template:
::
fuel environment
#. Upload the network template to Fuel:
::
fuel --env <ENV_ID> network-template --upload --dir <PATH>
**Example:**
::
fuel --env 1 network-template --upload --dir /home/stack/
#. Add or delete custom networks that you have introduced through
the network template:
* If you need to delete a network:
#. View the ID of the network by typing:
::
fuel network-group
**Example of system response:**
::
id | name | vlan_start | cidr | gateway |group_id
---+---------------+------------+--------------+----------+--------
24 | private | | | | 4
23 | private | | | | 5
22 | storage | 102 | 10.10.1.0/24 | 10.1.1.1 | 5
25 | management | 101 | 10.10.0.0/24 | 10.0.0.1 | 4
21 | public | | 10.10.0.0/24 | 10.10.0.1| 4
#. Delete the required network using the network ID.
::
fuel network-group --delete --env <env_id> --network <network_id>
* If you need to add a new network, type:
::
fuel network-group --create --node-group <node_group_id> --name
<network_name> --vlan <vlan_id> --cidr <cidr_id>
#. Add or delete custom networks as described in
:ref:`cli-network-group`.
#. Configure L2 and L3 network settings:
.. note:: You cannot modify VLAN settings through the Fuel web UI or CLI
Configure VLAN settings in the network template.
* Using Fuel web UI:
#. Log in to the Fuel web UI.
#. Click :guilabel:`Networks`.
#. Configure :guilabel:`Network Settings` as required.
.. note:: If you add additional node network group with different from the
default node network group settings, update the network template
with the required changes.
* Using Fuel CLI:
#. Log in to the Fuel CLI.
#. Download network configuration:
::
fuel --env <env_ID> network --download
#. Make the required changes in the network ``.yaml`` file.
#. Upload the configuration to the Fuel Master node:
::
fuel --env <env_ID> network --upload
.. seealso::
- :ref:`cli-network-group`
- :ref:`cli-network-template`

32
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-delete.rst Normal file
View File

@ -0,0 +1,32 @@
.. _network-template-delete:
Delete a network template
-------------------------
You can delete a network template that you have previously uploaded.
.. warning::
Do not delete network templates that are used in your OpenStack
environment as it may result in failure of the whole network
configuration.
**To delete a network template:**
#. Log in to the Fuel Master node CLI.
#. Type:
::
fuel --env <ENV_ID> network-template --delete
**Example:**
::
fuel --env 1 network-template --delete
.. seealso::
- :ref:`cli-network-group`
- :ref:`cli-network-template`

35
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-examples.rst Normal file
View File

@ -0,0 +1,35 @@
.. _network-templates-examples:
Network template examples
=========================
This section provides examples of network configurations
using network templates. You can use the default template
and modify it for your requirements or use any of the templates provided
in the `network templates folder </examples/network_templates.html>`_.
The following table describes network template examples:
.. list-table:: **Examples of network templates**
:widths: 10 10
:header-rows: 1
* - Template
- Description
* - ``default.yaml``
- The default network template deploys the basic configuration that you
can deploy using the Fuel web UI. You can use this template to create
your own network template. Additional information about network
configuration using network templates provided in the file.
* - ``one_network.yaml``
- A network template that describes a configuration in which one network
serves all traffic.
* - ``two_networks.yaml``
- A network template that describes a configuration in which all traffic
is served by two networks.
.. toctree::
:maxdepth: 1
examples/one-network.rst
examples/two-networks.rst

18
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-limitations.rst Normal file
View File

@ -0,0 +1,18 @@
.. _network-templates-limitations:
Network template limitations
----------------------------
When using network templates, consider the following limitations:
* All operations with templates must be performed through CLI or API.
The Fuel web UI does not support network templates.
* The Public network which maps to the External network in OpenStack
cannot be removed.
* When you use network templates, do not download and modify Fuel
deployment configurations using the ``fuel download`` and
``fuel upload`` commands as it may result in system malfunction.
* Mapping of network roles to networks, as well as network topology cannot
be configured for individual nodes. They can only be set for a node role
or/and node group.
* Network verification in the Fuel web UI has limited support.

17
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-overview.rst Normal file
View File

@ -0,0 +1,17 @@
.. _network-templates-overview:
Overview of network templates
-----------------------------
A network template is a ``.yaml`` file that contains network configuration
for an OpenStack environment. To apply custom network
configurations, create and configure
the template according to your environment requirements. For your convenience,
use the following :ref:` Network template examples`.
The name of the network template
must follow this convention: ``network_template_<ENV_ID>.yaml``. Verify the
ID of your OpenStack environment by running the ``fuel environment`` command.
For example, if the ID of an OpenStack environment is ``1``, the name of the
template is ``network_template_1.yaml``.

19
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure.rst Normal file
View File

@ -0,0 +1,19 @@
.. _network-templates-structure:
Structure of network templates
------------------------------
You can use the structure described in this section, as well
as the default template, to create a template that meets the
requirements of your configuration.
Network parameters are defined in the ``adv_net_template``
section in the ``network_template_<ENV_ID>.yaml`` file.
.. toctree::
:maxdepth: 1
network-templates-structure/network_scheme.rst
network-templates-structure/nic_mapping.rst
network-templates-structure/templates_for_node_role.rst
network-templates-structure/network_assignment.rst

27
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/network_assignment.rst Normal file
View File

@ -0,0 +1,27 @@
.. _network-assignment:
network_assignment
------------------
**Description**
Describes mapping between endpoints and network names. The **Example**
section describes the mapping that Fuel configures by default
without using templates. The set of networks can be changed
using API.
**Example**
::
network_assignments:
storage:
ep: br-storage
private:
ep: br-prv
public:
ep: br-ex
management:
ep: br-mgmt
fuelweb_admin:
ep: br-fw-admin

200
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/network_scheme.rst Normal file
View File

@ -0,0 +1,200 @@
.. _network-scheme:
network_scheme
--------------
**Description**
Defines the name of the network template as well as the following
parameters that are applied to each network that needs to be
configured:
* ``priority`` - defines the order in which the network templates will
be applied to a node. The values range 0 to 64000.
For example, you can set ``100``, ``200``, ``300`` with ``100``
being the highest priority template.
* ``transformations`` - a sequence of actions that builds the required
network configuration. For example: ``add-br`` - add a network
bridge, ``add-port`` - add a network port. The Puppet L23network
module creates network objects described in the ``transformations``
section that connect physical interfaces with logical endpoints. Order
of commands specified in this section is significant.
The sequence of commands that create network configuration must
be reflected in the transformation section:
* For service networks:
#. Create a Linux bridge. By default, if you do not specify a
provider a Linux bridge is created.
#. Create a network port that connects the Linux bridge and the
physical network interface.
* For workload networks:
#. Create an OVS bridge as a first point of connection between
the OpenStack Networking service and the physical network
interface.
#. Create a Linux bridge. Since an OVS bridge cannot directly connect
to a physical interface, a Linux bridge is required.
#. Create a patch that connects Linux and OVS bridges.
#. Create a network port that connects the Linux bridge and the
physical network interface.
You can specify the following commands in the ``transformation``
section:
* ``add-br`` - creates a bridge. By default, creates a Linux
bridge. You can specify the following parameters for this command:
* ``name`` - name of the network bridge. For example, ``br-admin``.
* ``provider`` - a network technology such as Open vSwitch (OVS) or
Linux Bridge, that connects physical interface with
the OpenStack Networking service. Default provider is Linux
Bridge. The options are: ``linux``, ``ovs``.
* ``mtu`` - (optional) enables you to specify MTU for this network bridge.
* ``add-port`` - create a port that connects a Linux bridge with a
physical network interface. You can specify the following parameters
for this command:
* ``name`` - name of the network port.
* ``bridge`` - name of the bridge for which the port is created.
* ``type`` - (optional) A type of the OVS interface for the port.
Default value is ``internal``. Available options include:
``internal``, ``system``, ``tap``, ``gre``, ``null``.
See the OVS documentation for more details. Specify
* ``trunks`` - (optional) a set of 802.1q tags in the form of integers
from 0 to 4095) that are allowed to pass through if the "tag"
option equals 0. Available options include:
* Empty list - all traffic passes
* 0 - untagged traffic only.
* 2-4095 - traffic with the specified tag passes.
For example, 10,10,20.
* ``port_properties`` - (optional) a list of additional OVS port
properties to modify them in OVS database.
* ``interface_properties`` (optional) a list of additional OVS interface
properties to modify them in OVS database.
* ``add-patch`` - connects network bridges. Available parameters include:
* ``bridges`` - a pair of bridges to connect. You can specify either
bridges of the same type or of different types.
* ``peers`` - (optional) abstract names for each end of the patch.
* ``tags`` - (optional) a pair of integers that represent an
802.1q tag of traffic that is captured from a corresponding
OVS bridge. Available values include:
* 0 - only the untagged traffic passes through
* 1-4094 - the bond allows only the traffic with the specific tag.
Specify the tags in the ``trunks`` parameter.
* ``trunks`` - (optional) a set of 802.1q tags in a form of
integers from 2 to 4095 which are allowed to pass through if the
``tag`` parameter is set to ``0``. Available values include:
* Empty list - all traffic passes (default)
* 0 - untagged traffic only
* 2-4095 - traffic with the specified tag passes). For example, 0,10,20.
* ``add-bond`` - combines two or more network interfaces for redundancy
and creates a network object called bond. You can specify
the following parameters for this command:
* ``name`` - name of the network port.
* ``interfaces`` - a set of two or more network interfaces that you
want to bind. For example, ``eth1, eth2``.
* ``bridge`` - name of the bridge on which the bond must be created.
* ``tag`` - (optional) a 802.1q tag of traffic which
received from an OVS bridge. Available values include:
* 0 - the bond ignores the tag and allows all traffic to pass
through.
* 1 - 4094 - the bond allows only the traffic with the specific tag.
Specify the tags in the ``trunks`` parameter.
* ``trunks`` - (optional) a set of 802.1q tags in a form of
integers from 2 to 4095 which are allowed to pass through if the
``tag`` parameter is set to ``0``. Available values include:
* Empty list - all traffic passes (default)
* 0 - untagged traffic only
* 2-4095 - traffic with the specified tag passes). For example, 0,10,20.
* ``properties`` - (optional) a list of additional OVS bonded port
properties to modify them in the OVS database. Use this parameter
to set the aggregation mode and balancing strategy, to configure LACP,
and so on. For more informations, see the OVS documentation.
* ``endpoints`` - lists logical interfaces or bridges
with assigned IP addresses to which you can map one or more network
roles.
* ``roles`` - mapping of a network traffic to a logical endpoint. When you
apply multiple templates to one node, verify that this parameter
in one template does not contradict this parameter in other templates.
The list of supported network traffics (network roles) is available in the
``openstack.yaml`` file on the Fuel Master node. If you have Fuel plugins
installed in your environment, you can also map network traffic related
to the plugin. For the list of types of network traffic related to the
plugin, see the corresponding ``network_roles.yaml`` file in the plugin
repository.
The ``roles`` section cannot be empty. If you do not want to specify any
mappings, you must create one fake mapping. For example:
**Example:**
::
roles:
fake/ext: br-pub-ext
**Example**
::
network_scheme:
storage: <template name>
priority:
...
transformations:
...
endpoints:
...
roles:
...
private: <template name>
priority:
...
transformations:
...
endpoints:
...
roles:
...
.. seealso::
- `Network template spec
<https://specs.openstack.org/openstack/fuel-specs/specs/7.0/networking-templates.html>`_
- `Virtual IP reservation for Fuel plugins
<https://wiki.openstack.org/wiki/Fuel/Plugins#Virtual_IP_reservation_via_Fuel_Plugin.27s_metadata>`_

30
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/nic_mapping.rst Normal file
View File

@ -0,0 +1,30 @@
.. _nic-mapping:
nic_mapping
-----------
**Description**
Specifies aliases to network interface names mapping,
for example, ``adm: eth0``. If a node is not listed in this section,
default mapping applies. You can configure custom mapping for
any node by the node name. The number of NICs depends on the
network topology and may vary. Aliases are optional and if
all nodes have the same number of NICs connected in a similar
manner, you can use NIC names instead.
**Example**
::
nic_mapping:
default:
adm: eth0
pub: eth1
man: eth2
stor: eth3
node-33:
adm: eth0
pub: eth4
man: eth1
stor: eth2

35
userdocs/fuel-user-guide/configure-environment/network-templates/network-templates-structure/templates_for_node_role.rst Normal file
View File

@ -0,0 +1,35 @@
.. _templates-for-node-role:
templates_for_node_role
-----------------------
**Description**
List of network schemes for every node role used in the environment.
The order of the template names is significant and must be provided
according to your configuration requirements. For example, first
the Puppet module must create a network bridge and then the
corresponding sub-interface and not vice versa. While templates
can be reused for different node roles, each template is executed
once for every node.
When several roles are mixed on one node and no priority is set,
an alphabetical order of node roles is used to determine the final
order of the templates.
**Example**
::
templates_for_node_role:
controller:
- public
- private
- storage
- common
compute:
- common
- private
- storage
ceph-osd:
- common
- storage