Composable networks require special handling for IPv6

[Dan Sneddon]

Composable networks allows custom networks, and generates the Heat templates that create the network resources on the fly via Jinja2. Due to legacy constraints the initial patch series wasn't able to replace the existing IPv6 version of the built-in isolated networks.

In order to enable this functionality, we will have to create 2 versions of the network templates for each built-in isolated network, e.g. network/external.yaml and network/external_v6.yaml.

This should be fixed so that the existing templates can be removed.

[Emilien Macchi (emilienm)]

Will be fixed by https://review.openstack.org/#/c/499385

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/499385
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=dd299f08bd6b1df43760148d83ce9b6e09ba6572
Submitter: Jenkins
Branch: master

commit dd299f08bd6b1df43760148d83ce9b6e09ba6572
Author: Dan Sneddon <email address hidden>
Date: Wed Aug 30 11:26:52 2017 -0700

    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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/500146

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/500146
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=d88a8dc52ab4331a45a0cd92cf886274cccea73c
Submitter: Jenkins
Branch: stable/pike

commit d88a8dc52ab4331a45a0cd92cf886274cccea73c
Author: Dan Sneddon <email address hidden>
Date: Wed Aug 30 11:26:52 2017 -0700

    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
    (cherry picked from commit dd299f08bd6b1df43760148d83ce9b6e09ba6572)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/tripleo-heat-templates 7.0.0.0rc2 release candidate.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/tripleo-heat-templates 8.0.0.0b1 development milestone.