Bug 1716857

Description of problem:

The following traces can be found in neutron server.log:
2019-06-03 11:31:33.865 1 ERROR neutron     LOG.debug("Retry wrapper got retriable exception: %s", e)
2019-06-03 11:31:33.865 1 ERROR neutron   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2019-06-03 11:31:33.865 1 ERROR neutron     self.force_reraise()
2019-06-03 11:31:33.865 1 ERROR neutron   File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise
2019-06-03 11:31:33.865 1 ERROR neutron     six.reraise(self.type_, self.value, self.tb)
2019-06-03 11:31:33.865 1 ERROR neutron   File "/usr/lib/python2.7/site-packages/neutron/db/api.py", line 122, in wrapped
2019-06-03 11:31:33.865 1 ERROR neutron     return f(*dup_args, **dup_kwargs)

2019-06-03 11:31:33.865 1 ERROR neutron   File "/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/type_vlan.py", line 69, in _sync_vlan_allocations
<=====
2019-06-03 11:31:33.865 1 ERROR neutron     allocs = vlanalloc.VlanAllocation.get_objects(ctx)
2019-06-03 11:31:33.865 1 ERROR neutron   File "/usr/lib/python2.7/site-packages/neutron/objects/base.py", line 577, in get_objects
2019-06-03 11:31:33.865 1 ERROR neutron     return [cls._load_object(context, db_obj) for db_obj in db_objs]
2019-06-03 11:31:33.865 1 ERROR neutron   File "/usr/lib/python2.7/site-packages/neutron/objects/base.py", line 502, in _load_object
2019-06-03 11:31:33.865 1 ERROR neutron     obj.from_db_object(db_obj)
2019-06-03 11:31:33.865 1 ERROR neutron   File "/usr/lib/python2.7/site-packages/neutron/objects/base.py", line 445, in from_db_object
2019-06-03 11:31:33.865 1 ERROR neutron     setattr(self, field, fields[field])
2019-06-03 11:31:33.865 1 ERROR neutron   File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line 72, in setter
2019-06-03 11:31:33.865 1 ERROR neutron     field_value = field.coerce(self, name, value)
2019-06-03 11:31:33.865 1 ERROR neutron   File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/fields.py", line 195, in coerce
2019-06-03 11:31:33.865 1 ERROR neutron     return self._type.coerce(obj, attr, value)
2019-06-03 11:31:33.865 1 ERROR neutron   File "/usr/lib/python2.7/site-packages/neutron/objects/common_types.py", line 55, in coerce
2019-06-03 11:31:33.865 1 ERROR neutron     raise ValueError(msg)
2019-06-03 11:31:33.865 1 ERROR neutron ValueError: Field value 0 is invalid


I managed to reproduce the issue this way:

# mysql ovs_neutron;
MariaDB [(none)]> insert into ml2_vlan_allocations values ("tenant",0,1);



> select * from ml2_vlan_allocations;
+------------------+---------+-----------+
| physical_network | vlan_id | allocated |
+------------------+---------+-----------+
| tenant           |       0 |         1 |  <===== vlan_id 0 causes the issue
| tenant           |    1000 |         1 | 
| tenant           |    1001 |         1 |
| tenant           |    1002 |         1 |
| tenant           |    1003 |         1 |
| tenant           |    1004 |         1 |


I think it could come from something like :

 plugins/ml2/ml2_conf.ini:network_vlan_ranges=physnet1:0:2999

or from Director something like:

 NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-vlan'
 NeutronNetworkVLANRanges: 'tenant:0:299'


I'm still waiting for customer confirmation (that may not come )

As for wikipedia:

https://en.wikipedia.org/wiki/IEEE_802.1Q#Frame_format
VLAN identifier (VID)
    A 12-bit field specifying the VLAN to which the frame belongs. The hexadecimal values of 0x000 and 0xFFF are reserved. <=====
All other values may be used as VLAN identifiers, allowing up to 4,094 VLANs. The reserved value 0x000 indicates that the frame does not carry a VLAN ID; in this case, the 802.1Q tag specifies only a priority (in PCP and DEI fields) and is referred to as a priority tag. On bridges, VID 0x001 (the default VLAN ID) is often reserved for a network management VLAN; this is vendor-specific. The VID value 0xFFF is reserved for implementation use; it must not be configured or transmitted. 0xFFF can be used to indicate a wildcard match in management operations or filtering database entries.[7]


So I think it should be discused if we want to allow vlan 0 on that field, but definetly we should have a warning be value is 0 since the error could be difficult to catch

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
Unsure

Actual results:
Trace, it doesn't give a clue about the problem

Expected results:
A clear error