apex-tripleo-heat-templates - Unnamed repository

Age	Commit message (Collapse)	Author	Files	Lines
2017-09-01	Remove ipv6 specific network templates	Dan Sneddon	1	-91/+1
	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 (cherry picked from commit dd299f08bd6b1df43760148d83ce9b6e09ba6572)
2017-08-15	Convert network templates to be rendered via j2	Steven Hardy	1	-3/+3
	Use the network.network.j2.yaml to render these files, instead of relying on the hard-coded versions. Note this doesn't currently consider the _v6 templates as we may want to deprecate these and instead rely on an ipv6 specific network_data file, or perhaps make the network/network.network.j2.yaml generic and able to detect the version from the cidr? Change-Id: I662e8d0b3737c7807d18c8917bfce1e25baa3d8a Partially-Implements: blueprint composable-networks
2017-08-08	Fix cidr get_attr in custom networks	Giulio Fidente	1	-2/+1
	We were missing the square brackets around the list of arguments for get_attr when building the networks cidr output. This passed CI because Heat does not fail validation and Ceph (which is consuming the cidr output) is tested with a single network (ctlplane) which does not build the output using the same templates. Change-Id: I40bba0784a30295cb0d4eda1fbff20ebac85db99 Closes-Bug: #1709464
2017-07-26	Render isolated network templates using jinja2	Dan Sneddon	1	-0/+92
	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