Bug 1276908

Summary: RFE: no need for --neutron-network-type, since neutron supports xvlan and gre side-by-side anyways
Product: Red Hat OpenStack Reporter: Udi Kalifon <ukalifon>
Component: python-rdomanager-oscpluginAssignee: RHOS Maint <rhos-maint>
Status: CLOSED WONTFIX QA Contact: Shai Revivo <srevivo>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.0 (Kilo)CC: dsneddon, hbrock, jcoufal, jrist, jslagle, mburns, nyechiel, opavlenk, rhel-osp-director-maint
Target Milestone: ---Keywords: FutureFeature
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-13 05:23:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Udi Kalifon 2015-11-01 07:50:37 UTC 
Description of problem:
I deployed with "--neutron-network-type gre --neutron-tunnel-types gre,vxlan" and I was able to create a gre network and a vxlan network side-by-side on the same deployment. My external network was a vlan network and I assigned floating IPs from it to instances on both internal networks and had no problem communicating between the instances and the world.

So why do we need to pass --neutron-network-type at all? If neutron is capable of dynamically creating both types of networks after the deployment, why do we specify one during deployment? Could we just always support both?

It is not clear what --neutron-network-* does and how it affects the installation, and it's pretty messed up (see bug 1244893 also). If my understanding of neutron is correct, we better just cancel this parameter.


Version-Release number of selected component (if applicable):
python-rdomanager-oscplugin-0.0.10-8.el7ost.noarch


How reproducible:
100%
Comment 3 Mike Burns 2016-04-07 20:54:03 UTC 
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 5 Ola Pavlenko 2016-10-05 15:38:01 UTC 
Hi,

We are planning to remove the command (-neutron-tunnel-types and -neutron-network-type )

Are there any customers that require these? Is there any use case here?
Comment 6 Nir Yechiel 2016-10-06 04:45:20 UTC 
(In reply to Ola Pavlenko from comment #5)
> Hi,
> 
> We are planning to remove the command (-neutron-tunnel-types and
> -neutron-network-type )
> 
> Are there any customers that require these? Is there any use case here?

I am lacking some more context here. Was this change proposed and discussed upstream? @Dan what is your take on this?

Thanks,
Nir
Comment 7 Dan Sneddon 2016-10-06 17:24:22 UTC 
(In reply to Ola Pavlenko from comment #5)
> Hi,
> 
> We are planning to remove the command (-neutron-tunnel-types and
> -neutron-network-type )
> 
> Are there any customers that require these? Is there any use case here?

I don't think that is a good idea. The neutron network type value doesn't just enable the network types, but also sets their preference. The first network type listed will be used as the default for tenant networks. If all possible networks are in use for a given network type, then new networks will be created with the next network type. This allows an operator to specify that tenant networks should be VLAN, but have a fallback to VXLAN if all VLANs are exhausted.

We have too many customers who used these parameters in their original installation, who will be expecting those commands to work when they upgrade. Those same customers won't have those values specified in their THT environment files, so an upgrade which lacked that info could have the result of changing the Neutron network type which is the default for new tenant networks.

Unfortunately, the command-line implementation of these parameters have shown multiple bugs over multiple releases, so there is certainly a lack of trust in those commands. The best way to set these values is by using THT parameters in an environment file. We can deprecate those parameters on the command-line and issue a warning for a release or two, then delete these params. That will alert users that the settings have changed and they should update their environment files to specify the desired network and tunneling type defaults.

In any case, this discussion needs to happen upstream. Perhaps create a Launchpad BZ requesting that the command-line parameters be deprecated in favor of parameter_default settings in an environment file.
Comment 8 Dan Sneddon 2016-10-06 17:30:32 UTC 
Just to add some context to this, here is what is supposed to happen when you set those parameters:

--neutron-network-type vlan,vxlan --neutron-tunnel-types vxlan

This would result in tenant networks being created with type VLAN until all VLANs in the allowable range have been assigned, then vxlan networks being assigned after that. The admin would be able to create other network types, but with the default policy.json tenants would not have any control over their network type, and would get what the operator specified in those CLI params.

Now, if I were to deploy without those parameters specified, the defaults would kick in. The default in this case is for tenant networks to be of type VXLAN. So if those CLI params were removed, and I did an upgrade without specifying network type in an environment file, the default tenant network would change from VLAN to VXLAN.
Comment 9 Jason E. Rist 2016-10-13 05:23:24 UTC 
As per Dan's comment, closing as wontfix and moving upstream.