summaryrefslogtreecommitdiffstats
path: root/j2_excludes.yaml
AgeCommit message (Collapse)AuthorFilesLines
2017-09-01Remove ipv6 specific network templatesDan Sneddon1-6/+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-21Render port templates via j2Steven Hardy1-24/+0
Remove these from the j2 excludes and instead render all the networks to avoid duplication. Change-Id: Id8e14e06ffe959c50456b4c88fef306046a8b478 Partially-Implements: blueprint composable-networks
2017-08-15Convert network templates to be rendered via j2Steven Hardy1-6/+0
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-11Convert cephstorage-role.yaml to role.role.j2.yamlSteven Hardy1-1/+3
Add some special-casing for backwards compatibility, such that the CephStorage role can be rendered via j2 for support of composable networks. Change-Id: Iee92bb6ee94963717d3a8ef400e7970f62576a0d Partially-Implements: blueprint composable-networks
2017-08-11Convert blockstorage-role.yaml to role.role.j2.yamlSteven Hardy1-2/+0
Add some special-casing for backwards compatibility, such that the BlockStorage role can be rendered via j2 for support of composable networks. Change-Id: Ia5fb5ff6dbe218710e95a69583ac289cf7b4af9e Partially-Implements: blueprint composable-networks
2017-08-11Convert objectstorage-role.yaml to role.role.j2.yamlSteven Hardy1-1/+0
Add some special-casing for backwards compatibility, such that the ObjectStorage role can be rendered via j2 for support of composable networks. Change-Id: I52abbefe2f5035059ccbed925990faab020c6c89 Partially-Implements: blueprint composable-networks
2017-08-11Convert compute-role.yaml to role.role.j2.yamlSteven Hardy1-1/+0
Add some special-casing for backwards compatibility, such that the Compute role can be rendered via j2 for support of composable networks. Change-Id: Ieee446583f77bb9423609d444c576788cf930121 Partially-Implements: blueprint composable-networks
2017-08-11Convert controller-role.yaml to role.role.j2.yamlSteven Hardy1-1/+0
Add deprecated role-specific parameters to role definition, in order to special-case some parameters for backwards compatibility, such that the Controller role can be rendered via j2 for support of composable networks. Co-Authored By: Dan Sneddon <dsneddon@redhat.com> Change-Id: I5983f03ae1b7f0b6add793914540b8ca405f9b2b Partially-Implements: blueprint composable-networks
2017-07-26Render isolated network templates using jinja2Dan Sneddon1-0/+36
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
2016-10-06Add generic template for custom roles.Carlos Camacho1-0/+10
This submission creates a generic template file to deploy custom roles. Also adds a file to specify an exclusion role list in order to avoid not to generate the template for those roles. Partial-Bug: #1626976 Depends-On: I6d7247bbb8702eb0ab9bdf133b5ab1c6e8349d98 Change-Id: I3e11c089023b793a5063d9e1714527a3fe2b7458