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
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
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>
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
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>
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
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
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
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
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
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
