Open Stack

Responses inline...

----- Original Message -----
> 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.

Coincidentally, I was working along similar lines in order to support multiple
routed subnets per network (for spine-and-leaf networking). In order to avoid
an exponential number of templates, it makes sense to work from a map of data
that defines the various networks, subnets, default routes, etc. that will
vary from rack to rack with routed networking, and then generate the
templates from that information.
 
> > 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.

I agree that it is possible, and that it will require testing to ensure that
we maintain backwards compatibility.

> 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.

I am biased, since I wrote the patchset [1], but I would like to merge the
networker.yaml role and then can backport it prior to refactoring the
NIC configs. In general, though, I think we can limit the number of NIC
configs to one per physical topology, and then enable/disable interfaces,
VLANs, routes, etc. for each role based on network connectivity.

[1] - https://review.openstack.org/#/c/400390/

> If we can do some of that during the Ocata timefram, I expect fully
> composable/custom networks may be possible during Pike?
> 
> Steve


--
Dan Sneddon         |  Senior Principal OpenStack Engineer
dsneddon at redhat.com |  redhat.com/openstack
dsneddon:irc        |  @dxs:twitter