Cisco nexus plugin fails to create vlan on a previously used switch

[Ralf Haferkamp]

When reconfiguring quantum from scratch with a cisco nexus switch that was previously used in a quantum setup, creating a VLAN might fail with:

QuantumClientException: Failed to configure Nexus:
 <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
        <configure>
          <__XML__MODE__exec_configure>
            <vlan>
              <vlan-id-create-delete>
                <__XML__PARAM_value>582</__XML__PARAM_value>
                <__XML__MODE_vlan>
                  <name>
                    <vlan-name>q-582</vlan-name>
                  </name>
                </__XML__MODE_vlan>
              </vlan-id-create-delete>
            </vlan>
          </__XML__MODE__exec_configure>
        </configure>
      </config>
. Reason: ERROR: VLAN with the same name exists

The workaround for this is pretty easy. Just delete (even renaming seems to be enough) all the vlans that quantum is supposed to manage on the switch using the configuration console.

But couldn't the nexus plugin also simply overwrite the exisiting VLAN in case it already exists on the switch but not it the database?

[Henry Gessau (gessau)]

I am uncomfortable with changing the existing behavior. A pre-existing VLAN on the switch may have been set up by another admin who does not want neutron to overwrite it.

Instead, we could add a new configuration option, say "clear_vlans_on_init", which would cause neutron to clear any existing unused VLANs from the tenant VLAN range at startup.

[Aaron Rosen (arosen)]

Out of curiosity why does neutron need to on demand program vlans on the switche(s). Why not as part of setup have the admin trunk a range of vlans they want to use and tell neturon about that. That seems like it would simplify things greatly?

[Sam Betts (sambetts)]

Does this need moving over to the networking-cisco vendor repo bug tracker, if its still a valid issue?