Open Stack

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.

Thanks,
-- 
Emilien Macchi