28 Commits

Author SHA1 Message Date
James Slagle
c7a97ce997 Add external_resource_vip_id property to network_data.yaml
Adds the external_resource_vip_id property, which can be used to set an
external_id for the port resource for the network VIP.

Since the same template resource, port.network.j2.yaml is used for both
VIP and normal ports on a network, we can't simply add jinja to that
template that conditionally adds the external_id attribute because we
don't know during the jinja2 phase if the template is for a VIP or not.

Instead, we need to map the VIP resources to an entirely new template
resource (external_resource_port.network.j2.yaml) so that we can set the
external_id attribute just for the VIP ports.

Change-Id: I27d3eeb11277004b00aa4d6a66014d5c71081c26
implements: blueprint split-controlplane-templates
2019-03-25 10:48:40 -04:00
James Slagle
c4eb9688d7 Add external_resource_id properties to network_data.yaml
Adds the ability to set external_resource_id for the network,
external_resource_subnet_id for the subnet(s), and
external_resource_segment_id for the segment(s) to network_data.yaml.

When setting these properties, the external_id attribute will be set on
the corresponding Heat resources. This causes Heat to not re-create
these resources and instead adopt them from outside the stack.

When using network isolation with multiple stacks (e.g.,
split-controlplane), this allows for re-using some of the same
networks and resources from the non-control plane stacks.

Change-Id: I6652ef8a5105843f4b2cdec54062bd25a57809a0
2019-03-25 10:48:40 -04:00
Zuul
f5394e7e2d Merge "Allow overlay tunnel endpoints on IPv6 address" 2019-01-10 21:13:19 +00:00
Janki Chhatbar
fe8b808fd3 Allow overlay tunnel endpoints on IPv6 address
Overlay tunnel endpoints are supported only on
IPv4 address. Now that OVS and Neutron support
having v6 endpoints, edit network enviroment
files in TripleO to allow this.

Change-Id: Ie2523cf4e359289298e4ea5d0992093976a19e04
Closes-Bug: #1793239
2019-01-10 10:26:24 +00:00
Harald Jensås
91985cfbce L3 routed networks - data + env (1/3)
Render composable network L3 routed subnets in
network-environment yaml files.

Partial: blueprint tripleo-routed-networks-templates
Change-Id: I4ba234ede5b7f243ba41e8fec8f78e1f1cc261c8
2018-12-30 19:24:29 +01:00
Harald Jensås
e644e3dda9 Add MTU to neutron networks and nic-config templates
Neutron has support[1] to set the guaranteed MTU for
networks and network segments so that this is exposed
to plug-ins. In interest of supporting the use of
plug-ins to configure network devices in the future
this change adds MTU property on neutron networks.

The new (optional) property 'mtu' in the network
defenitions in 'network_data.yaml' is used to control
the MTU settings. By default the mtu is '1500'.

We already configure the MTU on the ctlplane neutron
networks, this adds the MTU to composable networks.

Also update the nic-config sample templates to include
mtu settings. A heat value resource is added to
nic-config templates to get the required minimum
viable MTU value for bridges, bonds and member
interfaces to ensure the MTU is large enough to allow
the largest configured MTU to traverse the path.

Closes-Bug: #1790537
Change-Id: I11e38f82eb9040f77412fe8ad200fcc48031e2f8
2018-12-22 17:03:09 +01:00
Sorin Sbarnea
446dcc179d Fix fs035 by defining a default gateway_ipv6
Change-Id: I95e2a659927f44e2941b10daa10c7fc9c605bbd8
Closes-Bug: 1806897
2018-12-05 14:23:51 +00:00
Dan Sneddon
2fb91cd5b0 Add a gateway IP to the Management net in network_data.yaml
In several places in our documentation, we discuss enabling
the Management network as a default route in some cases.
However, we don't set this value by default. Setting a
gateway IP in the example versions of network_data.yaml
would help to demonstrate this, and would create a good
default for testing.

Change-Id: Ibbb2a403f0733a016f1f49b4acdbdcfe7b9ab5a3
2018-09-04 18:33:36 -07:00
Harald Jensås
4e1d12b4c7 Fix typo in network_data files
The comments use ipv6_gateway, while the actual data
and code uses gateway_ipv6. This changes the comments
to use gateway_ipv6 as well.

Change-Id: I3b173fca479e778f75307b7bb47bd7954ea786f4
2018-08-20 08:25:15 +02:00
Zuul
5fadfd093f Merge "Add host routes to subnets" 2018-08-14 19:40:21 +00:00
Zuul
06e1751be1 Merge "Correct spelling" 2018-08-06 17:40:42 +00:00
Harald Jensås
4e44547533 Add host routes to subnets
This change adds a new routes field to the network
definition in network_data.yaml. This field contains
a list of network routes in JSON, e.g.
  [{'destination':'10.0.0.0/16','nexthop':'10.0.0.1'}].

This list is used to set the ``host_routes`` property
of each networks subnet.

Co-Authored-By: Dan Sneddon <dsneddon@redhat.com>
Partial: blueprint tripleo-routed-networks-templates
Depends-On: Ifc5aad7a154c33488a7613c8ee038c92ee6cb1a7
Change-Id: I33b34f1445f4203fbf25edeb093b37c7494c664f
2018-07-30 09:42:19 +02:00
Bob Fournier
d3eb296e19 Add default value for name_lower in network_data.yaml to update ServiceNetMap
In Pike and later, the name_lower field in network_data.yaml can be
re-defined to contain a custom network name.  When this is done the
ServiceNetMap field must be overridden to reflect the new name in all
places.  This changes adds a new optional field to network_data.yaml
that should be set to the original default name_lower value.
ServiceNetMap will then be automatically updated and will not need
to be overridden.

This also fixes the VipPort naming for the StorageManagement network
to not use a static value.

Change-Id: I8a238038122288899cef49faf38ea2c2ffc2176b
2018-06-28 10:17:28 -04:00
Ivan Pesin
d0f402298f Correct spelling
Correct spelling in configuration yaml files.

Change-Id: Ib0e29c7e426a86185cf5e9f3e09f65f91e3ae57f
2018-06-18 12:52:14 +00:00
Marius Cornea
9932c2841c Enable management network in network_data
This change enables the management network in network_data to allow
upgrading environments that were initially deployed with this optional
network enabled.

Change-Id: I39b1a70f0a27bdab4d6280d54107ff209d4bb67d
Closes-bug: 1765547
2018-04-20 15:40:03 -04:00
Lukas Bezdicka
5b9127cfc1 Return old ranges to network_data.yaml
In change 'Render NIC config templates with jinja2' there was also
change of IP ranges for networks. This change is backwards
incompatible and it's better to revert the ranges instead of making
compatibility workaround.

Change-Id: Ifd9f4abaf8b9ac18c251ab8cfba326f2fa92f796
2018-02-22 12:55:37 +01:00
Dan Sneddon
1dec175241 Render NIC config templates with jinja2
This change converts the existing NIC templates to jinja2 in
order to dynamically render the ports and networks according
to the network_data.yaml. If networks are added to the
network_data.yaml file, parameters will be added to all
NIC templates. The YAML files (as output from jinja with
the default network_data.yaml) are present as an example.

The roles in roles_data.yaml are used to produce NIC configs
for the standard and custom composable roles. In order to
keep the ordering of NICs the same in the multiple-nics
templates, the order of networks was changed in the
network_data.yaml file. This is reflected in the network
templates, and in some of the files that is the only
change.

The roles and roles_data.yaml were modified to include
a legacy name for the NIC config templates for the
built-in roles Controller, Compute, Object Storage,
Block Storage, Ceph Storage, Compute-DPDK, and
Networker roles. There will now be a file produced
with the legacy name, but also one produced with the
<role>-role.j2.yaml format (along with environment
files to help use the new filenames).

Note this change also fixes some typos as well as
a number of templates that had VLANs with device:
entries which were ignored.

Closes-Bug: 1737041
Depends-On: I49c0245c36de3103671080fd1c8cfb3432856f35
Change-Id: I3bdb7d00dab5a023dd8b9c94c0f89f84357ae7a4
2018-02-13 00:19:37 -08:00
Tim Rozet
1fd272a308 Fixes InternalApi Heat network resource
Detection for using legacy network is now in tripleo-common so there is
no need to set it network_data.yaml anymore.

Depends-On: I695259ad87e2303f948875078bccb619786470e0

Closes-Bug: 1718764

Change-Id: I52468a687ba7215ec32c5700de346b3ed4ebd1f9
Signed-off-by: Tim Rozet <trozet@redhat.com>
2017-10-16 15:41:39 -04:00
Jenkins
23f2e683ed Merge "Revert "Fixes heat resource name for Internal API Network"" 2017-10-13 09:56:56 +00:00
Tim Rozet
8817c546d3 Revert "Fixes heat resource name for Internal API Network"
This reverts commit 97244b942d29d2b5acd7a3eb07acdba0d9b99677.

This introduced a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1501515

where during upgrade, the previous heat resource would for the
InternalApi network would have the incorrect name "Internal" and the
upgrade would try to delete the resource in order to create
"InternalApi".  This needs to be reverted and a proper fix will be
submitted that accounts for this upgrade scenario.

Related-Bug: #1718764

Change-Id: Ied908020ed856a5573f1333b9139029d0ffc37b4
2017-10-12 15:55:40 -04:00
Jenkins
79e283c1fb Merge "Fixes heat resource name for Internal API Network" 2017-10-04 18:07:57 +00:00
Tim Rozet
97244b942d Fixes heat resource name for Internal API Network
With the dynamic Jinja2 rendering for networks, the heat resource for
Internal API network was accidentally being renamed to:
OS::TripleO::Network::Internal

when it should be the same as previous versions:
OS::TripleO::Network::InternalApi

This patch removes the 'compat_name' which was overriding the network
name for rendering the resource. This patch also removes the
compat_name functionality from the network/networks.j2.yaml file
since it is no longer needed.

Closes-Bug: 1718764

Change-Id: If756cddd91933edb303cc056515d98b941a3eb14
Signed-off-by: Tim Rozet <trozet@redhat.com>
2017-09-27 17:50:51 -07:00
Dan Sneddon
5b9fbc2b2b Fix upgrades that use Management network
Upgrades from older versions using Management network fail.
This patch enables the management network even though it is not
enabled in any of the role definitions. This will allow upgrades
to complete using existing network environment files, without
requiring operators to switch to the new method for defining
which networks are attached to roles. Eventually these older
environment files will be removed.

Change-Id: Iadd12a559f0ad6918958a1355f189187fd327363
Closes-bug: 1717123
2017-09-20 15:24:17 -07:00
Dan Sneddon
dd299f08bd Remove ipv6 specific network templates
This change renders the IPv6 versions of the isolated
networks using j2. To allow for backward compatibility,
there will be 2 versions of the network definitions,
<network>.yaml and <network>_v6.yaml. If the ip_subnet
contains an IPv6 address, or if ipv6: true is set on the
network definition in network_data.yaml, then the
<network>.yaml version will contain an IPv6 definition,
otherwise the <network>.yaml will be IPv4, and the
<network>_v6.yaml will be IPv6.

In a future follow-up patch, we will probably only
create the required versions of the networks, either
IPv4, IPv6, not both.

The ipv6_subnet, ipv6_allocation_pools, and ipv6_gateway
settings in the network_data.yaml definition file are
used for the <network>_v6.yaml network definition.
Note that these subnet/cidr/gateway definitions only set
the defaults, which can be overridden with parameters
set in an environment file.

Since the parameters for IP and subnet range are the
same (e.g. InternalApiNetCidr applies to both IPv4/v6),
only one version can be used at a time. If an operator
wishes to use dual-stack IPv4/IPv6, then two different
networks should be created, and both networks can be
applied to a single interface.

Note that the workflow for the operator is the same as
before this change, but a new example template has been
added to environments/network-environment-v6.yaml.

Change-Id: I0e674e4b1e43786717ae6416571dde3a0e11a5cc
Partially-Implements: blueprint composable-networks
Closes-bug: 1714115
2017-08-31 13:12:17 -07:00
Sofer Athlan-Guyot
a8a1d5b30c Keep dynamic network creation backward compatible.
We had an history mapping for InternalApi to InternalNetwork.  If we
remove it then heat will want to destroy InternalNetwork and create
InternalApi which cannot work during upgrade.

This adds compat name parameters to network_data.yaml.

Closes-Bug: #1709105

Change-Id: I8ce6419a5e13a13ee6e991db5ca2196763f52d7a
2017-08-08 14:01:08 +02:00
Dan Sneddon
6d68ce08e1 Render isolated network templates using jinja2
This change adds templates that are used to create network and
port definition templates for each network that is defined in
network_data.yaml. In order to render the templates, additional
fields have been added to the network_data.yaml file. If this
optional data is present, it will be used to populate the default
parameter values in the network template.

The only required parameters in the network_data.yaml file is
the network name. If the network will have IPv6 addresses, then
ipv6: true must be set on the network.

The existing networks have been modeled in the network_data.yaml,
but until these templates are removed from the j2_excludes.yaml
file they will not be generated on the fly. Any additional
networks will have templates generated.

This change also removes an unnecessary conditional from the
networks.j2.yaml file, since InternalApiNetwork doesn't need
to be reformatted as InternalNetwork (it's only used in this
one file).

A follow-up patch will remove the existing network definitions
so all networks are created dynamically.

Change-Id: If074f87494a46305c990a0ea332c7b576d3c6ed8
Depends-On: Iab8aca2f1fcaba0c8f109717a4b3068f629c9aab
Partially-Implements: blueprint composable-networks
2017-07-26 11:43:12 -07:00
Giulio Fidente
baf6eee501 Adds network/cidr mapping into a new service property
Makes it possible to resolve network subnets within a service
template; the data is transported into a new property ServiceData
wired into every service which hopefully is generic enough to
be extended in the future and transport more data.

Data can be consumed in service templates to set config values
which need to know what is the subnet where a deamon operates (for
example the Ceph Public vs Cluster network).

Change-Id: I28e21c46f1ef609517175f7e7ee19e28d1c0cba2
2017-07-14 13:44:04 +02:00
Steven Hardy
a5116005d8 Add network_data.yaml to encapsulate list of networks for j2
This moves the hard-coded networks from the default environment,
and provides the first step towards enabling composable networks.

Co-Author: Dan Sneddon <dsneddon@redhat.com>
Partial-Bug: #1633090
Depends-On: I9f818912bd8e2a3220e41c8ccbbab3d9063b4d72
Change-Id: I7793b8badede5450b05437c84d9b40c28de7546b
2017-03-05 03:20:42 +00:00