On Mon, Dec 12, 2016 at 4:21 PM, Steven Hardy <[email protected]> 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. Thanks, -- Emilien Macchi __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
