[openstack-dev] [TripleO] Re-defining network templates/isolation

Emilien Macchi emilien at redhat.com
Tue Dec 13 15:55:02 UTC 2016

On Mon, Dec 12, 2016 at 4:21 PM, Steven Hardy <shardy at redhat.com> wrote:
> On Mon, Dec 12, 2016 at 12:12:30PM -0500, Tim Rozet wrote:
>> Hello,
>> I wanted to get thoughts about re-thinking how users configure and create new networks with OOO.  The current way to configure network settings for a deployment requires creating nic + network environment templates, and updating the network isolation resource registry.  I think a better approach could consolidate all of the network settings for a deployment into a single yaml file, and then parse that information to create the appropriate nic and network env templates.  We do that in OPNFV Apex with a combination of python and jinja2 using this unified template format:
>> https://github.com/opnfv/apex/blob/master/config/network/network_settings.yaml
> Thanks for sharing, and for raising this issue Tim.
> Strangely enough I was thinking along similar lines recently and I started
> hacking on some prototype code, just pushed here:
> https://review.openstack.org/#/c/409920
> https://review.openstack.org/#/c/409921
> That was originally related to fixing this bug where network isolation is
> a little inconvenient to use when defining custom roles:
> https://bugs.launchpad.net/tripleo/+bug/1633090
> Basically I agree we need some way to define per-network data that can then
> be consumed by jinja2 when we render templates for each role.
>> Furthermore consider cdefining new networks in OOO.  Think about how much is involved in creating a new network, subnet, port definition + net_ip_map for that network, VIP. If you look at the tht/network directory, almost all of the templates for ports and networks have the exact same format.  I think you could make the example above dynamic so that a user could define any new network there and the corresponding port, network + subnet template files could be created on the fly.
> Yes, I agree, this could be the next step after enabling the current
> networks for custom roles.  If we do the j2 implementation right for fixing
> the bug above, I think enabling arbitrary additional networks e.g via some
> j2 loops shouldn't be too much additional work.
>> I think this creates a much more simple interface for users by exposing networking configuration they need, but also hiding redundant OOO/heat template syntax they don't necessarily care about.  Thoughts?
> So, yeah basically I agree - we should reduce the duplication between
> templates e.g for nic configuration, and j2 render them where possible for
> each role/network.
> The trick here will be doing it so that we maintain backwards compatibility
> - if we're careful that's probably possible, but we'll have to figure out
>   ways to test that ensure we don't break existing users.
> My suggestion would be to refactor things to resolve the bug above, and
> possibly also https://bugs.launchpad.net/tripleo/+bug/1625558 which I think
> should really be fixed by generating the nic configs, not adding even more
> example templates.
> If we can do some of that during the Ocata timefram, I expect fully
> composable/custom networks may be possible during Pike?

Thanks Steve for your inputs, it sounds like we have a plan.
Tim, would you mind to draft a tripleo-specs that we would target for pike?
So we could start early discussions and make sure we can make it on
time by end of Pike cycle.

Emilien Macchi

More information about the OpenStack-dev mailing list