summaryrefslogtreecommitdiffstats
path: root/network_data.yaml
AgeCommit message (Collapse)AuthorFilesLines
2017-10-04Fixes heat resource name for Internal API NetworkTim Rozet1-1/+0
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> (cherry picked from commit 97244b942d29d2b5acd7a3eb07acdba0d9b99677)
2017-09-22Fix upgrades that use Management networkDan Sneddon1-2/+3
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 (cherry picked from commit 5b9fbc2b2bfa00de2fe0f437f21e05e3fc09a53d)
2017-09-01Remove ipv6 specific network templatesDan Sneddon1-12/+37
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-08Keep dynamic network creation backward compatible.Sofer Athlan-Guyot1-0/+3
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-07-26Render isolated network templates using jinja2Dan Sneddon1-4/+33
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-14Adds network/cidr mapping into a new service propertyGiulio Fidente1-0/+4
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-03-05Add network_data.yaml to encapsulate list of networks for j2Steven Hardy1-0/+30
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