NIC config templates should be rendered to support composable networks

[Dan Sneddon]

The NIC config templates in network/config/*/<Role>.yaml should be generated by Jinja to support composable networks. This will save a lot of manual work when creating custom networks.

When a custom network is added, the parameters for the <network>IpSubnet need to be added to every NIC config file, whether the network is used or not, in order to avoid Heat errors. This is due to the fallback mechanism which outputs the control plane IP if an IP is not found on a network, and that IP has to be written to a parameter, so it must exist.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/539727
Committed: https://git.openstack.org/cgit/openstack/tripleo-common/commit/?id=bc65df3c32ac770f84b8a93af64dc1f8b650f637
Submitter: Zuul
Branch: master

commit bc65df3c32ac770f84b8a93af64dc1f8b650f637
Author: Dan Sneddon <email address hidden>
Date: Wed Jan 31 14:45:00 2018 -0800

    Support deprecated NIC config names for legacy roles.

    This patch enables a fix for bug/1737041 while supporting upgrades
    from previous deployments where the NIC config template for the
    role does not match the composable role name ,e.g. cinder-storage
    for the BlockStorage role. This change looks for a property in
    network_data.yaml, deprecated_nic_config_name.

    Partial-Bug: 1737041
    Change-Id: I49c0245c36de3103671080fd1c8cfb3432856f35

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/542974

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/523638
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=1dec175241c7e5f3c85dbe0cb1d38909e1d52308
Submitter: Zuul
Branch: master

commit 1dec175241c7e5f3c85dbe0cb1d38909e1d52308
Author: Dan Sneddon <email address hidden>
Date: Tue Nov 28 17:00:59 2017 -0800

    Render NIC config templates with jinja2

    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

[OpenStack Infra (hudson-openstack)]

Change abandoned by Tom Barron (<email address hidden>) on branch: master
Review: https://review.openstack.org/542974

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/tripleo-heat-templates 8.0.0.0rc1 release candidate.

[Lokesh Jain (lokesh-jain)]

Hi Dan,

I am deploying an OpenStack cluster, with the code changes that you have proposed, with bonded VLANs and I am hitting issues. If I don't specify the device in vlan, I get the following error:

[ERROR] stdout: ERROR : [/sbin/ifup] PHYSDEV should be set for device vlan

If I set the value for device as "bond1" in the file "network/config/bond-with-vlans/role.role.j2.yaml", then the deployment works fine.

I was thinking of proposing this change upstream, but wanted to confirm with you first. Please provide your input on this.

Thanks and Regards,
Lokesh

[Dan Sneddon (dsneddon)]

Lokesh,

It is expected behavior that you need to specify the device when using Linux bonds (as opposed to OVS bonds). Did you modify bond-with-vlans/role.role.j2.yaml to use a linux_bond instead of ovs_bond?

I'd like to rectify that behavior so that OVS and Linux bonds act the same way, but that should probably be handled in a separate bug.

[Lokesh Jain (lokesh-jain)]

Hi Dan,

Didn't see your reply till now. Yes, you are right that we are working with linux_bond and that's when we noticed this.
Should I open another bug to handle the uniformity of OVS and Linux bonds? Please let me know.

Regards,
Lokesh