Network_data should dynamically render resource registry

[Tim Rozet]

Currently in TripleO the network_data.yaml file contains dynamic information about the definition of networks to be used in a deployment. It also includes an 'enabled' field to indicate whether or not a network is enabled. Today this information is used to render definitions of networks and ports in templates. However, it is not used to create the resource registry. This part is still required to do manually by including/modifying the network-isolation.yaml file. This creates an unnecessary step as the default resource registry could be set using network data.

This proposal is to change the rendering in overcloud.j2 and other files so that the default ports and networks will be rendered according to the network_data.yaml file. This means that a user will only have to modify the network_data file in order to declare a new network and enable isolation. If a user has some reason to override the dynamically generated resource registry, he/she will still be able to include via '-e network-isolation.yaml' to override the defaults as previously done.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Change abandoned by Emilien Macchi (<email address hidden>) on branch: master
Review: https://review.openstack.org/509190
Reason: Per policy, this patch will be abandoned: https://github.com/openstack/tripleo-specs/blob/master/specs/policy/patch-abandomment.rst#when-to-abandon

You can restore it at anytime if you think the patch will be updated.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Alex Schultz (<email address hidden>) on branch: master
Review: https://review.openstack.org/509190
Reason: Abandoning this patch per the TripleO Patch Abandonment guidelines (https://specs.openstack.org/openstack/tripleo-specs/specs/policy/patch-abandonment.html). If you wish to have this restored and cannot do so yourself, please reach out via #tripleo on freenode or the OpenStack Dev mailing list.