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? Steve __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
