[openstack-dev] [TripleO] Re-defining network templates/isolation
shardy at redhat.com
Mon Dec 12 21:21:53 UTC 2016
On Mon, Dec 12, 2016 at 12:12:30PM -0500, Tim Rozet wrote:
> 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:
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:
That was originally related to fixing this bug where network isolation is
a little inconvenient to use when defining custom roles:
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
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
If we can do some of that during the Ocata timefram, I expect fully
composable/custom networks may be possible during Pike?
More information about the OpenStack-dev