Network Data v2 - node ports spec
Partial-Implements: blueprint network-data-v2-ports Change-Id: Iae721c373f2bbfffa36ed2db9d9af6569e15ed96
This commit is contained in:
parent
2fda7fdcfa
commit
93bc0b3faf
|
@ -0,0 +1,675 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
====================================================
|
||||||
|
Network Data v2 - node ports and node network config
|
||||||
|
====================================================
|
||||||
|
|
||||||
|
With "Network Data v2" the goal is to move management of network resources
|
||||||
|
out of the heat stack. The schema spec [1]_ talked about the
|
||||||
|
``network_data.yaml`` format and managing networks, segments and subnets. This
|
||||||
|
spec follows up with node ports for composable networks and moving the node
|
||||||
|
network configuration action to the baremetal/network configuration workflow.
|
||||||
|
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Applying a network change on day 2, currently requires a full stack update
|
||||||
|
since network resources such as ports are managed by heat. It has also been
|
||||||
|
problematic to create ports for large scale deployments; neutron on the single
|
||||||
|
node undercloud gets overwhelmed and it is difficult to throttle port creation
|
||||||
|
in Heat. As an early indication on the performance of port creation with the
|
||||||
|
proposed ansible module:
|
||||||
|
|
||||||
|
Performance stats: 100 nodes x 3 networks = 300 ports
|
||||||
|
|
||||||
|
.. code-block:: text
|
||||||
|
|
||||||
|
4xCPU 1.8 GHz (8GB) 8x CPU 2.6 GHz (12GB)
|
||||||
|
------------------- --------------------------------
|
||||||
|
Concurr: 10 20 10 4
|
||||||
|
........ .............. ......... ......... .........
|
||||||
|
Create real 5m58.006s 1m48.518s 1m51.998s 1m25.022s
|
||||||
|
Delete: real 4m12.812s 0m47.475s 0m48.956s 1m19.543s
|
||||||
|
Re-run: real 0m19.386s 0m4.389s 0m4.453s 0m4.977s
|
||||||
|
|
||||||
|
|
||||||
|
Proposed Change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Extend the baremetal provisioning workflow that runs before overcloud
|
||||||
|
deployment to also create ports for composable networks. The baremetal
|
||||||
|
provisioning step already create ports for the provisioning network. Moving
|
||||||
|
the management of ports for composable networks to this workflow will
|
||||||
|
consolidate all port management into one workflow.
|
||||||
|
|
||||||
|
Also make baremetal provisioning workflow execute the tripleo-ansible
|
||||||
|
``tripleo_network_config`` role to configure node networking after
|
||||||
|
node provisioning.
|
||||||
|
|
||||||
|
The deploy workflow would be:
|
||||||
|
|
||||||
|
#. Operator defines composable networks in network data YAML file.
|
||||||
|
#. Operator provisions composable networks by running the
|
||||||
|
``openstack overcloud network provision`` command, providing the network
|
||||||
|
data YAML file as input.
|
||||||
|
#. Operator defines roles and nodes in the baremetal deployment YAML file. This
|
||||||
|
YAML also defines the networks for each role.
|
||||||
|
#. Operator deploys baremetal nodes by running the
|
||||||
|
``openstack overcloud node provision`` command. This step creates ports in
|
||||||
|
neutron, and also configures networking; including composable networks; on
|
||||||
|
the nodes using ansible role to apply network config with os-net-config
|
||||||
|
[2]_.
|
||||||
|
#. Operator deploys heat stack including the environment files produced by the
|
||||||
|
commands executed in the previous steps by running the
|
||||||
|
``openstack overcloud deploy`` command.
|
||||||
|
#. Operator executes config-download to install and configure openstack on the
|
||||||
|
overcloud nodes. *(optional - only if overcloud deploy command executed with
|
||||||
|
``-stack-only``)*
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
Harald Jensås <hjensas@redhat.com>
|
||||||
|
|
||||||
|
Approver(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary approver:
|
||||||
|
TODO
|
||||||
|
|
||||||
|
|
||||||
|
Implementation Details
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
The baremetal YAML definition will be extended, adding the ``networks`` and the
|
||||||
|
``network_config`` keys in role ``defaults`` as well as per-instance to support
|
||||||
|
``fixed_ip`` addressing, manually pre-created port resource and per-node
|
||||||
|
network configuration template.
|
||||||
|
|
||||||
|
The ``networks`` will replace the current ``nic`` key, until the ``nic`` key is
|
||||||
|
deprecated either can be used but not both at the same time. Networks in
|
||||||
|
``networks`` will support a boolean key ``vif`` which indicate if the port
|
||||||
|
should be attached in Ironic or not. If no network with ``vif: true`` is
|
||||||
|
specified an implicit one for the control plane will be appended:
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
- network: ctlplane
|
||||||
|
vif: true
|
||||||
|
|
||||||
|
For networks with ``vif: true``, ports will be created by metalsmith. For
|
||||||
|
networks with ``vif: false`` (or ``vif`` not specified) the workflow will
|
||||||
|
create neutron ports based on the YAML definition.
|
||||||
|
|
||||||
|
The neutron ports will initially be tagged with the *stack name* and the
|
||||||
|
instance *hostname*, these tags are used for idempotency. The ansible module
|
||||||
|
managing ports will get all ports with the relevant tags and then add/remove
|
||||||
|
ports based on the expanded roles defined in the Baremetal YAML definition.
|
||||||
|
(The *hostname* and *stack_name* tags are also added to ports created with heat
|
||||||
|
in this tripleo-heat-templates change [4]_, to enable *adoption* of neutron
|
||||||
|
ports created by heat for the upgrade scenario.)
|
||||||
|
|
||||||
|
Additionally the ports will be tagged with the ironic node uuid when this is
|
||||||
|
available. Full set of tags are shown in the example below.
|
||||||
|
|
||||||
|
.. code-block:: json
|
||||||
|
|
||||||
|
{
|
||||||
|
"port": {
|
||||||
|
"name": "controller-1-External",
|
||||||
|
"tags": ["tripleo_ironic_uuid=<IRONIC_NODE_UUID>",
|
||||||
|
"tripleo_hostname=controller-1",
|
||||||
|
"tripleo_stack_name=overcloud"],
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
.. Note:: In deployments where baremetal nodes have multiple physical NIC's
|
||||||
|
multiple networks can have ``vif: true``, so that VIF attach
|
||||||
|
in ironic and proper neutron port binding happens. In a scenario
|
||||||
|
where neutron on the Undercloud is managing the switch this would
|
||||||
|
enable automation of the Top-of-Rack switch configuration.
|
||||||
|
|
||||||
|
Mapping of the port data for overcloud nodes will go into a ``NodePortMap``
|
||||||
|
parameter in tripleo-heat-tempaltes. The map will contain submaps for each
|
||||||
|
node, keyed by the node name. Initially the ``NodePortMap`` will be consumed by
|
||||||
|
alternative *fake-port*
|
||||||
|
``OS::TripleO::{{role.name}}::Ports::{{network.name}}Port`` resource templates.
|
||||||
|
In the final implementation the environment file created can be extended and
|
||||||
|
the entire ``OS::TripleO::{{role.name}}`` resource can be replaced with a
|
||||||
|
template that references parameter in the generated environment directly, i.e a
|
||||||
|
re-implemented ``puppet/role.role.j2.yaml`` without the server and port
|
||||||
|
resources. The ``NodePortMap`` will be added to the
|
||||||
|
*overcloud-baremetal-deployed.yaml* created by the workflow creating the
|
||||||
|
overcloud node port resources.
|
||||||
|
|
||||||
|
Network ports for ``vif: false`` networks, will be managed by a new ansible
|
||||||
|
module ``tripleo_overcloud_network_ports``, the input for this role will be a
|
||||||
|
list of instance definitions as generated by the
|
||||||
|
``tripleo_baremetal_expand_roles`` ansible module. The
|
||||||
|
``tripleo_baremetal_expand_roles`` ansible module will be extended to add
|
||||||
|
network/subnet information from the baremetal deployment YAML definition.
|
||||||
|
|
||||||
|
The baremetal provision workflow will be extended to write a ansible inventory,
|
||||||
|
we should try extend tripleo-ansible-inventory so that the baremetal
|
||||||
|
provisioning workflow can re-use existing code to create the inventory.
|
||||||
|
The inventory will be used to configure networking on the provisioned nodes
|
||||||
|
using the **triple-ansible** ``tripleo_network_config`` ansible role.
|
||||||
|
|
||||||
|
|
||||||
|
Already Deployed Servers
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The Baremetal YAML definition will be used to describe the **pre-deployed**
|
||||||
|
servers baremetal deployment. In this scenario there is no Ironic node to
|
||||||
|
update, no ironic UUID to add to a port's tags and no ironic node to attach
|
||||||
|
VIFs to.
|
||||||
|
|
||||||
|
All ports, including the ctlplane port will be managed by the
|
||||||
|
``tripleo_overcloud_network_ports`` ansible module. The Baremetal YAML
|
||||||
|
definition for a deployment with pre-deployed servers will have to include an
|
||||||
|
``instance`` entry for each pre-deployed server. This entry will have the
|
||||||
|
``managed`` key set to ``false``.
|
||||||
|
|
||||||
|
It should be possible for an already deployed server to have a management
|
||||||
|
address that is completely separate from the tripleo managed addreses. The
|
||||||
|
Baremetal YAML definition can be extended to carry a ``management_ip`` field
|
||||||
|
for this purpose. In the case no managment address is available the ctlplane
|
||||||
|
network entry for pre-deployed instances must have ``fixed_ip`` configured.
|
||||||
|
|
||||||
|
The deployment workflow will *short circuit* the baremetal provisioning of
|
||||||
|
``managed: false`` instances. The Baremetal YAML definition can define a
|
||||||
|
mix of *already deployed server* instances, and instances that should be
|
||||||
|
provisioned via metalsmith. See :ref:`baremetal_yaml_pre_provsioned`.
|
||||||
|
|
||||||
|
YAML Examples
|
||||||
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Example: Baremetal YAML definition with defaults properties
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
- name: Controller
|
||||||
|
count: 1
|
||||||
|
hostname_format: controller-%index%
|
||||||
|
defaults:
|
||||||
|
profile: control
|
||||||
|
network_config:
|
||||||
|
template: templates/multiple_nics/multiple_nics.j2
|
||||||
|
physical_bridge_name: br-ex
|
||||||
|
public_interface_name: nic1
|
||||||
|
network_deployment_actions: ['CREATE']
|
||||||
|
net_config_data_lookup: {}
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
vif: true
|
||||||
|
- network: external
|
||||||
|
subnet: external_subnet
|
||||||
|
- network: internal_api
|
||||||
|
subnet: internal_api_subnet
|
||||||
|
- network: storage
|
||||||
|
subnet: storage_subnet
|
||||||
|
- network: storage_mgmt
|
||||||
|
subnet: storage_mgmt_subnet
|
||||||
|
- network: Tenant
|
||||||
|
subnet: tenant_subnet
|
||||||
|
- name: Compute
|
||||||
|
count: 1
|
||||||
|
hostname_format: compute-%index%
|
||||||
|
defaults:
|
||||||
|
profile: compute
|
||||||
|
network_config:
|
||||||
|
template: templates/multiple_nics/multiple_nics.j2
|
||||||
|
physical_bridge_name: br-ex
|
||||||
|
public_interface_name: nic1
|
||||||
|
network_deployment_actions: ['CREATE']
|
||||||
|
net_config_data_lookup: {}
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
vif: true
|
||||||
|
- network: internal_api
|
||||||
|
subnet: internal_api_subnet
|
||||||
|
- network: tenant
|
||||||
|
subnet: tenant_subnet
|
||||||
|
- network: storage
|
||||||
|
subnet: storage_subnet
|
||||||
|
|
||||||
|
Example: Baremetal YAML definition with per-instance overrides
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
- name: Controller
|
||||||
|
count: 1
|
||||||
|
hostname_format: controller-%index%
|
||||||
|
defaults:
|
||||||
|
profile: control
|
||||||
|
network_config:
|
||||||
|
template: templates/multiple_nics/multiple_nics.j2
|
||||||
|
physical_bridge_name: br-ex
|
||||||
|
public_interface_name: nic1
|
||||||
|
network_deployment_actions: ['CREATE']
|
||||||
|
net_config_data_lookup: {}
|
||||||
|
bond_interface_ovs_options:
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
vif: true
|
||||||
|
- network: external
|
||||||
|
subnet: external_subnet
|
||||||
|
- network: internal_api
|
||||||
|
subnet: internal_api_subnet
|
||||||
|
- network: storage
|
||||||
|
subnet: storage_subnet
|
||||||
|
- network: storage_mgmt
|
||||||
|
subnet: storage_mgmt_subnet
|
||||||
|
- network: tenant
|
||||||
|
subnet: tenant_subnet
|
||||||
|
instances:
|
||||||
|
- hostname: controller-0
|
||||||
|
name: node00
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
vif: true
|
||||||
|
- network: internal_api:
|
||||||
|
fixed_ip: 172.21.11.100
|
||||||
|
- hostname: controller-1
|
||||||
|
name: node01
|
||||||
|
networks:
|
||||||
|
External:
|
||||||
|
port: controller-1-external
|
||||||
|
- hostname: controller-2
|
||||||
|
name: node02
|
||||||
|
- name: ComputeLeaf1
|
||||||
|
count: 1
|
||||||
|
hostname_format: compute-leaf1-%index%
|
||||||
|
defaults:
|
||||||
|
profile: compute-leaf1
|
||||||
|
networks:
|
||||||
|
- network: internal_api
|
||||||
|
subnet: internal_api_subnet
|
||||||
|
- network: tenant
|
||||||
|
subnet: tenant_subnet
|
||||||
|
- network: storage
|
||||||
|
subnet: storage_subnet
|
||||||
|
instances:
|
||||||
|
- hostname: compute-leaf1-0
|
||||||
|
name: node03
|
||||||
|
network_config:
|
||||||
|
template: templates/multiple_nics/multiple_nics_dpdk.j2
|
||||||
|
physical_bridge_name: br-ex
|
||||||
|
public_interface_name: nic1
|
||||||
|
network_deployment_actions: ['CREATE']
|
||||||
|
net_config_data_lookup: {}
|
||||||
|
num_dpdk_interface_rx_queues: 1
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
vif: true
|
||||||
|
- network: internal_api
|
||||||
|
fixed_ip: 172.21.12.105
|
||||||
|
- network: tenant
|
||||||
|
port: compute-leaf1-0-tenant
|
||||||
|
- network: storage
|
||||||
|
subnet: storage_subnet
|
||||||
|
|
||||||
|
|
||||||
|
.. _baremetal_yaml_pre_provsioned:
|
||||||
|
|
||||||
|
Example: Baremetal YAML for Already Deployed Servers
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
- name: Controller
|
||||||
|
count: 3
|
||||||
|
hostname_format: controller-%index%
|
||||||
|
defaults:
|
||||||
|
profile: control
|
||||||
|
network_config:
|
||||||
|
template: templates/multiple_nics/multiple_nics.j2
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
- network: external
|
||||||
|
subnet: external_subnet
|
||||||
|
- network: internal_api
|
||||||
|
subnet: internal_api_subnet
|
||||||
|
- network: storage
|
||||||
|
subnet: storage_subnet
|
||||||
|
- network: storage_mgmt
|
||||||
|
subnet: storage_mgmt_subnet
|
||||||
|
- network: tenant
|
||||||
|
subnet: tenant_subnet
|
||||||
|
managed: false
|
||||||
|
instances:
|
||||||
|
- hostname: controller-0
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
fixed_ip: 192.168.24.10
|
||||||
|
- hostname: controller-1
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
fixed_ip: 192.168.24.11
|
||||||
|
- hostname: controller-2
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
fixed_ip: 192.168.24.12
|
||||||
|
- name: Compute
|
||||||
|
count: 2
|
||||||
|
hostname_format: compute-%index%
|
||||||
|
defaults:
|
||||||
|
profile: compute
|
||||||
|
network_config:
|
||||||
|
template: templates/multiple_nics/multiple_nics.j2
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
- network: internal_api
|
||||||
|
subnet: internal_api_subnet
|
||||||
|
- network: tenant
|
||||||
|
subnet: tenant_subnet
|
||||||
|
- network: storage
|
||||||
|
subnet: storage_subnet
|
||||||
|
instances:
|
||||||
|
- hostname: compute-0
|
||||||
|
managed: false
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
fixed_ip: 192.168.24.100
|
||||||
|
- hostname: compute-1
|
||||||
|
managed: false
|
||||||
|
networks:
|
||||||
|
- network: ctlplane
|
||||||
|
fixed_ip: 192.168.24.101
|
||||||
|
|
||||||
|
Example: NodeNetworkDataMappings
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
NodePortMap:
|
||||||
|
controller-0:
|
||||||
|
ctlplane:
|
||||||
|
ip_address: 192.168.24.9 (2001:DB8:24::9)
|
||||||
|
ip_subnet: 192.168.24.9/24 (2001:DB8:24::9/64)
|
||||||
|
ip_address_uri: 192.168.24.9 ([2001:DB8:24::9])
|
||||||
|
internal_api:
|
||||||
|
ip_address: 172.18.0.9 (2001:DB8:18::9)
|
||||||
|
ip_subnet: 172.18.0.9/24 (2001:DB8:18::9/64)
|
||||||
|
ip_address_uri: 172.18.0.9 ([2001:DB8:18::9])
|
||||||
|
tenant:
|
||||||
|
ip_address: 172.19.0.9 (2001:DB8:19::9)
|
||||||
|
ip_subnet: 172.19.0.9/24 (2001:DB8:19::9/64)
|
||||||
|
ip_address_uri: 172.19.0.9 ([2001:DB8:19::9])
|
||||||
|
compute-0:
|
||||||
|
ctlplane:
|
||||||
|
ip_address: 192.168.24.15 (2001:DB8:24::15)
|
||||||
|
ip_subnet: 192.168.24.15/24 (2001:DB8:24::15/64)
|
||||||
|
ip_address_uri: 192.168.24.15 ([2001:DB8:24::15])
|
||||||
|
internal_api:
|
||||||
|
ip_address: 172.18.0.15 (2001:DB8:18::1)
|
||||||
|
ip_subnet: 172.18.0.15/24 (2001:DB8:18::1/64)
|
||||||
|
ip_address_uri: 172.18.0.15 ([2001:DB8:18::1])
|
||||||
|
tenant:
|
||||||
|
ip_address: 172.19.0.15 (2001:DB8:19::15)
|
||||||
|
ip_subnet: 172.19.0.15/24 (2001:DB8:19::15/64)
|
||||||
|
ip_address_uri: 172.19.0.15 ([2001:DB8:19::15])
|
||||||
|
|
||||||
|
Example: Ansible inventory
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
Controller:
|
||||||
|
vars:
|
||||||
|
role_networks:
|
||||||
|
- External
|
||||||
|
- InternalApi
|
||||||
|
- Tenant
|
||||||
|
role_networks_lower:
|
||||||
|
External: external
|
||||||
|
InternalApi: internal_api
|
||||||
|
Tenant: tenant
|
||||||
|
networks_all:
|
||||||
|
- External
|
||||||
|
- InternalApi
|
||||||
|
- Tenant
|
||||||
|
neutron_physical_bridge_name: br-ex
|
||||||
|
neutron_public_interface_name: nic1
|
||||||
|
tripleo_network_config_os_net_config_mappings: {}
|
||||||
|
network_deployment_actions: ['CREATE', 'UPDATE']
|
||||||
|
ctlplane_subnet_cidr: 24
|
||||||
|
ctlplane_mtu: 1500
|
||||||
|
ctlplane_gateway_ip: 192.168.24.254
|
||||||
|
ctlplane_dns_nameservers: []
|
||||||
|
dns_search_domains: []
|
||||||
|
ctlplane_host_routes: {}
|
||||||
|
internal_api_cidr: 24
|
||||||
|
internal_api_gateway_ip: 172.18.0.254
|
||||||
|
internal_api_host_routes: []
|
||||||
|
internal_api_mtu: 1500
|
||||||
|
internal_api_vlan_id: 20
|
||||||
|
tenant_cidr: 24
|
||||||
|
tenant_api_gateway_ip: 172.19.0.254
|
||||||
|
tenant_host_routes: []
|
||||||
|
tenant_mtu: 1500
|
||||||
|
hosts:
|
||||||
|
controller-0:
|
||||||
|
ansible_host: 192.168.24.9
|
||||||
|
ctlplane_ip: 192.168.24.9
|
||||||
|
internal_api_ip: 172.18.0.9
|
||||||
|
tenant_ip: 172.19.0.9
|
||||||
|
Compute:
|
||||||
|
vars:
|
||||||
|
role_networks:
|
||||||
|
- InternalApi
|
||||||
|
- Tenant
|
||||||
|
role_networks_lower:
|
||||||
|
InternalApi: internal_api
|
||||||
|
Tenant: tenant
|
||||||
|
networks_all:
|
||||||
|
- External
|
||||||
|
- InternalApi
|
||||||
|
- Tenant
|
||||||
|
neutron_physical_bridge_name: br-ex
|
||||||
|
neutron_public_interface_name: nic1
|
||||||
|
tripleo_network_config_os_net_config_mappings: {}
|
||||||
|
network_deployment_actions: ['CREATE', 'UPDATE']
|
||||||
|
ctlplane_subnet_cidr: 24
|
||||||
|
ctlplane_mtu: 1500
|
||||||
|
ctlplane_gateway_ip: 192.168.25.254
|
||||||
|
ctlplane_dns_nameservers: []
|
||||||
|
dns_search_domains: []
|
||||||
|
ctlplane_host_routes: {}
|
||||||
|
internal_api_cidr: 24
|
||||||
|
internal_api_gateway_ip: 172.18.1.254
|
||||||
|
internal_api_host_routes: []
|
||||||
|
internal_api_mtu: 1500
|
||||||
|
internal_api_vlan_id: 20
|
||||||
|
tenant_cidr: 24
|
||||||
|
tenant_api_gateway_ip: 172.19.1.254
|
||||||
|
tenant_host_routes: []
|
||||||
|
tenant_mtu: 1500
|
||||||
|
hosts:
|
||||||
|
compute-0:
|
||||||
|
ansible_host: 192.168.25.15
|
||||||
|
ctlplane_ip: 192.168.25.15
|
||||||
|
internal_ip: 172.18.1.15
|
||||||
|
tenant_ip: 172.19.1.15
|
||||||
|
|
||||||
|
|
||||||
|
TODO
|
||||||
|
----
|
||||||
|
|
||||||
|
* Constraint validation, for example ``BondInterfaceOvsOptions`` uses
|
||||||
|
``allowed_pattern: ^((?!balance.tcp).)*$`` to ensure balance-tcp bond mode is
|
||||||
|
not used, as it is known to cause packet loss.
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
#. Write ansible inventory after baremetal provisioning
|
||||||
|
|
||||||
|
Create an ansible inventory, similar to the inventory created by config-
|
||||||
|
download. The ansible inventory is required to apply network
|
||||||
|
configuration to the deployed nodes.
|
||||||
|
|
||||||
|
We should try to extend tripleo-ansible-inventory so that the baremetal
|
||||||
|
provisioning workflow can re-use existing code to create the inventory.
|
||||||
|
|
||||||
|
It is likely that it makes sense for the workflow to also run the
|
||||||
|
tripleo-ansible role tripleo_create_admin to create the *tripleo-admin*
|
||||||
|
ansible user.
|
||||||
|
|
||||||
|
#. Extend baremetal provisioning workflow to create neutron ports and
|
||||||
|
update the ironic node ``extra`` field with the ``tripleo_networks`` map.
|
||||||
|
|
||||||
|
#. The baremetal provisioning workflow needs a *pre-deployed-server* option
|
||||||
|
that cause it to not deploy baremetal nodes, only create network ports.
|
||||||
|
When this option is used the baremetal deployment YAML file will also
|
||||||
|
describe the already provisioned nodes.
|
||||||
|
|
||||||
|
#. Apply and validate network configuration using the **triple-ansible**
|
||||||
|
``tripleo_network_config`` ansible role. This step will be integrated in
|
||||||
|
the provisioning command.
|
||||||
|
|
||||||
|
#. Disable and remove management of composable network ports in
|
||||||
|
tripleo-heat-templates.
|
||||||
|
|
||||||
|
#. Change the Undercloud and Standalone deploy to apply network configuration
|
||||||
|
prior to the creating the ephemeral heat stack using the
|
||||||
|
``tripleo_network_config`` ansible role.
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
Multinode OVB CI job's with network-isolation will be updated to test the new
|
||||||
|
workflow.
|
||||||
|
|
||||||
|
Upgrade Impact
|
||||||
|
==============
|
||||||
|
|
||||||
|
During upgrade switching to use network ports managed outside of the heat stack
|
||||||
|
the ``PortDeletionPolicy`` must be set to ``retain`` during the update/upgrade
|
||||||
|
*prepare* step, so that the existing neutron ports (which will be adopted by
|
||||||
|
the pre-heat port management workflow) are not deleted when running the update/
|
||||||
|
upgrade *converge* step.
|
||||||
|
|
||||||
|
Moving node network configuration out of tripleo-heat-templates will require
|
||||||
|
manual (or scripted) migration of settings controlled by heat template
|
||||||
|
parameters to the input file used for baremetal/network provisioning. At least
|
||||||
|
the following parameters are affected:
|
||||||
|
|
||||||
|
* NeutronPhysicalBridge
|
||||||
|
* NeutronPublicInterface
|
||||||
|
* NetConfigDataLookup
|
||||||
|
* NetworkDeploymentActions
|
||||||
|
|
||||||
|
Parameters that will be deprecated:
|
||||||
|
|
||||||
|
* NetworkConfigWithAnsible
|
||||||
|
* {{role.name}}NetworkConfigTemplate
|
||||||
|
* NetworkDeploymentActions
|
||||||
|
* {{role.name}}NetworkDeploymentActions
|
||||||
|
* BondInterfaceOvsOptions
|
||||||
|
* NumDpdkInterfaceRxQueues
|
||||||
|
* {{role.name}}LocalMtu
|
||||||
|
* NetConfigDataLookup
|
||||||
|
* DnsServers
|
||||||
|
* DnsSearchDomains
|
||||||
|
* ControlPlaneSubnetCidr
|
||||||
|
* HypervisorNeutronPublicInterface
|
||||||
|
* HypervisorNeutronPhysicalBridge
|
||||||
|
|
||||||
|
The environment files used to select one of the pre-defined nic config
|
||||||
|
templates will no longer work. The template to use must be set in the YAML
|
||||||
|
defining the baremetal/network deployment. This affect the following
|
||||||
|
environment files:
|
||||||
|
|
||||||
|
* environments/net-2-linux-bonds-with-vlans.j2.yaml
|
||||||
|
* environments/net-bond-with-vlans.j2.yaml
|
||||||
|
* environments/net-bond-with-vlans-no-external.j2.yaml
|
||||||
|
* environments/net-dpdkbond-with-vlans.j2.yaml
|
||||||
|
* environments/net-multiple-nics.j2.yaml
|
||||||
|
* environments/net-multiple-nics-vlans.j2.yaml
|
||||||
|
* environments/net-noop.j2.yaml
|
||||||
|
* environments/net-single-nic-linux-bridge-with-vlans.j2.yaml
|
||||||
|
* environments/net-single-nic-with-vlans.j2.yaml
|
||||||
|
* environments/net-single-nic-with-vlans-no-external.j2.yaml
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
The documentation effort is **heavy** and will need to be incrementally
|
||||||
|
updated. As a minumum, a separate page explaining the new process must be
|
||||||
|
created.
|
||||||
|
|
||||||
|
The TripleO docs will need updates in many sections, including:
|
||||||
|
|
||||||
|
* `TripleO OpenStack Deployment
|
||||||
|
<https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/install_overcloud.html>`_
|
||||||
|
* `Provisioning Baremetal Before Overcloud Deploy
|
||||||
|
<https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisioning/baremetal_provision.html#>`_
|
||||||
|
* `Deploying with Custom Networks
|
||||||
|
<https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/custom_networks.html>`_
|
||||||
|
* `Configuring Network Isolation
|
||||||
|
<https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/network_isolation.html>`_
|
||||||
|
* `Deploying Overcloud with L3 routed networking
|
||||||
|
<https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/routed_spine_leaf_network.html>`_
|
||||||
|
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
============
|
||||||
|
|
||||||
|
#. **Not changing how ports are created**
|
||||||
|
|
||||||
|
In this case we keep creating the ports with heat, the do nothing
|
||||||
|
alternative.
|
||||||
|
|
||||||
|
#. **Create a completely separate workflow for composable network ports**
|
||||||
|
|
||||||
|
A separate workflow that can run before/after node provisioning. It can read
|
||||||
|
the same YAML format as baremetal provisioning, or it can have it's own YAML
|
||||||
|
format.
|
||||||
|
|
||||||
|
The problem with this approach is that we loose the possibility to store
|
||||||
|
relations between neutron-port and baremetal node in a database. As in, we'd
|
||||||
|
need our own database (a file) maintaining the relationships.
|
||||||
|
|
||||||
|
.. Note:: We need to implement this workflow anyway for a pre-deployed
|
||||||
|
server scenario, but instead of a completely separate workflow
|
||||||
|
the baremetal deploy workflow can take an option to not
|
||||||
|
provision nodes.
|
||||||
|
|
||||||
|
#. **Create ports in ironic and bind neutron ports**
|
||||||
|
|
||||||
|
Instead of creating ports unknown to ironic, create ports for the ironic
|
||||||
|
nodes in the baremetal service.
|
||||||
|
|
||||||
|
The issue is that ironic does not have a concept of virtual port's, so we
|
||||||
|
would have to either add this support in ironic, switch TripleO to use
|
||||||
|
neutron trunk ports or create *fake* ironic ports that don't actually
|
||||||
|
reflect NICs on the baremetal node. (This abandoned ironic spec [3]_ discuss
|
||||||
|
one approach for virtual port support, but it was abandoned in favor of
|
||||||
|
neutron trunk ports.)
|
||||||
|
|
||||||
|
With each PTG there is a re-occurring suggestion to replace neutron with a
|
||||||
|
more light weight IPAM solution. However, the effort to actually integrate
|
||||||
|
it properly with ironic and neutron for composable networks probably isn't
|
||||||
|
time well spent.
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
.. [1] `Review: Spec for network data v2 format <https://review.opendev.org/752437>`_.
|
||||||
|
.. [2] `os-net-config <https://opendev.org/openstack/os-net-config>`_.
|
||||||
|
.. [3] `Abandoned spec for VLAN Aware Baremetal Instances <https://review.opendev.org/277853>`_.
|
||||||
|
.. [4] `Review: Add hostname and stack_name tags to ports <https://review.opendev.org/761845>`_.
|
Loading…
Reference in New Issue