Bug 1276908 - RFE: no need for --neutron-network-type, since neutron supports xvlan and gre side-by-side anyways
RFE: no need for --neutron-network-type, since neutron supports xvlan and gre...
Status: CLOSED WONTFIX
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-rdomanager-oscplugin (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
unspecified Severity medium
: ---
: 10.0 (Newton)
Assigned To: RHOS Maint
Shai Revivo
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-01 02:50 EST by Udi
Modified: 2016-10-13 01:23 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-10-13 01:23:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Udi 2015-11-01 02:50:37 EST
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 16:54:03 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 5 Ola Pavlenko 2016-10-05 11:38:01 EDT
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 00:45:20 EDT
(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 13:24:22 EDT
(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 13:30:32 EDT
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 01:23:24 EDT
As per Dan's comment, closing as wontfix and moving upstream.

Note You need to log in before you can comment on or make changes to this bug.